David Buck talks about a problem that can crop up when using Intellisense. I'd be curious to know how much this comes up. I don't use either of the auto-completion goodies in VW, and I don't do enough development in any of the environments with Intellisense to have a good notion.
I find this hilarious. Greasemonkey scripts work by effectively screen scrapping the website and inserting changes into the HTML. Stephen and others who are upset by Google's change are basically saying that Google should never change the HTML or URL structure of the website ever again because it breaks their scripts. Yeah, right. Repeat after me, a web page is not an API or a platform.
I'm getting a Spy vs. Spy (Mad magazine) visual here :)
Gartner's Office of the Ombudsman has launched its own blog. Written by two Gartner veteran analysts and Ombudsman program leaders -- Nancy Erskine and Larry Perlstein -- the weblog is intended to support "an open and frank discussion on topics related to Gartner's analytical independence, accuracy, and integrity."
In a snarky tone, he said "well then, there probably won't be many entries then - possibly none..."
Or even more snarkily: "Maybe there will be tons of posts, in order to explain the general lack of cluefulness..."
Real Tech News reports on a nifty gadget for the collector who has everything - of course, you have to be pretty well off to afford this as a gift:
“There is no greater anguish for a wine collector than to spend thousands of dollars on a 50-year-old bottle of Bordeaux, only to have it taste like vinegar when it’s opened. But now a New Jersey real estate developer and wine enthusiast says he has found a way to guarantee wine drinkers will never taste sour grapes again.
Like the Real Tech News folks said, you can file this under "problem solved that you don't have" :)
Apparently, MS is about to announce a few things about RSS and the way they are tying it into IE and Longhorn. There's also something of a controversy over a possibly violated NDA, but I have no idea about that - I certainly wasn't privy to any of that stuff :) CNet picked up the story here - and Paul Thurott (first link above) said that you should watch here for news. That last site has a feed.
Remember the legal ruling from the EU that forced MS to sell/ship a version of Windows XP without media player in Europe? Well, they have that version out there now, but it seems that the regulators are the only ones who want it:
Retailers in Europe report that there's no interest in the XP N versions. The problems are price and perception. Despite lacking a key feature of the mainstream XP versions, the XP N editions are priced identically to their non-N counterparts. Too, the lack of a media player means that XP N buyers need to manually download a media player, which, believe it or not, is still a daunting process for many people.
Some PC makers--notably Dell and Sony--have simply refused to ship the XP N editions. "From our experience, customers purchasing computers expect them to come equipped with the capability of playing back digital media files," a Dell spokesperson said.
Having fixed up more than one Windows installation in my time, I can verify that - I still recall my neighbors, who are not dumb by any means - but they couldn't get their printer installed, and it "only" required a download of the appropriate driver.
If you own a TiVo, or a Media Center PC, or a PVR from your cable company, you're part of an elite. A new research report from Accenture says that the percentage of U.S. homes with personal video recorders will increase by 500% in the next four years, but even in 2009 more than half of U.S. homes still won't have the equipment to record, pause, or time-shift TV.
To me, the problem is the difficulty in explaining a PVR to someone who doesn't have one. I get answers like "there's nothing good on anyway", or "we don't watch much tv anyway". The thing is, a PVR optimizes whatever you do watch - there are programs I watch now that I have no idea as to when they actually air :)
The bad thing is, the slow rate of adoption means that the current network tactic of starting or ending programs a few minutes early/late will keep happening :(
In a Slashdot story on cell phone use, an interesting side point got made about dealing with consumer complaints:
Also of note: Intelliseek's Pete Blackshaw 'says companies used to dismiss vocal complaints from one or two consumers as an aberration. But now, they have to pay attention because now those complainers may have blogs. '"
Steve Rubel points to a Gnomedex announcement - Audible is offering their audio content via secure (i.e., subscription) RSS:
They are making its wide selection of periodic audio content available via secure RSS. Audible customers can schedule automatic delivery of their periodic programming to their computers and to any one of more than 135 AudibleReady handheld devices.
BottomFeeder will deal with that nicely - you can use the Enclosure plugin to manage automatic downloads of the podcasts.
Cincom and Knowledge Systems Corp. are announcing a partnership around Cincom Smalltalk and services:
KSC to Provide Educational Services to Cincom Smalltalk(TM) Customers
CINCINNATI, OH -- (MARKET WIRE) -- 06/24/2005 -- Cincom Systems, a global leader in business process application development, announced today a strategic business alliance with Knowledge Systems Corporation (KSC), a leading provider of object-oriented services. KSC will provide training, mentoring, certification, and migration services to Cincom Smalltalk customers.
KSC, with expertise in the Cincom Smalltalk product line since 1985, is offering a variety of courses now available to Cincom Smalltalk customers:
- Object-Oriented Analysis and Design Workshop
- Introduction to Cincom Smalltalk VisualWorks®
- Effective Testing for Object-Oriented Programmers
- Advanced Cincom Smalltalk VisualWorks
- Tutoring in Smalltalk
"As the largest provider of commercial Smalltalk, we have the responsibility to provide the best product and services for the Smalltalk community," said Jim Hazel, Cincom, director U.S. services. "By partnering with KSC, we can enhance our Cincom Smalltalk user experience and continue to grow the Cincom Smalltalk community. KSC has the product expertise and Smalltalk course curriculum readily available to launch this relationship and services program immediately."
"Knowledge Systems Corporation is delighted to be working with Cincom. Cincom's drive and dedication for its Smalltalk products coupled with KSC's long history with Smalltalk makes for a natural partnership," said Allen Davis, CEO of KSC.
For nearly 40 years, Cincom's software and services have helped thousands of clients worldwide simplify the management of complex business processes. Cincom specializes in the five areas of business where simplification brings the greatest value to managers who want to grow revenue, control costs, minimize risk, and achieve rapid ROI better than their competitors: Data Management; Marketing, Sales and Customer Service; Application Development; Manufacturing; and Outsourcing/Hosting.
Cincom serves thousands of clients on six continents including BMW, Citibank, Boeing, Northwestern Mutual, Federal Express, Ericsson, Penn State University, Messier-Dowty, Siemens, Rockwell Automation, and Trane.
For more information about Cincom's products and services, contact Cincom at 1-800-2CINCOM (USA only), send an e-mail to firstname.lastname@example.org, or visit the company's website at www.cincom.com.
About Knowledge Systems Corporation
Established in 1985 and located in Cary, North Carolina, KSC is the world leader in Smalltalk education and services and has employed some of the nation's defining authorities on object technology. The bookshelves of programmers around the world reflect the contributions that KSC has made to enterprise software development. Used extensively in enterprise software development, Smalltalk is the best-supported, pure object-oriented programming language available.
KSC offers a longstanding success record and a wealth of technical expertise to its clients. KSC has worked with companies in numerous industries including: insurance, banking and financial, telecommunications, warehousing and distribution logistics, healthcare and manufacturing.
CINCOM, Cincom Smalltalk, VisualWorks, and The World's Most Experienced Software Company are trademarks or registered trademarks of Cincom Systems, Inc. All other trademarks belong to their respective companies.
© 2005 Cincom Systems, Inc.
Knowledge Systems Corporation
Cincom Systems, Inc.
SOURCE: Cincom Systems
Looks like MS has announced the big RSS news. The news? RSS integration into Longhorn (the OS) and IE. Apparently, the IE team is now the RSS team - you can see the Channel 9 video (warning - 1 hour long) here.
As usual with these channel 9 videos, the whole interview format just irritates me. I would much, much rather have a screencast showing me the cool stuff instead of an hour of blather that I really don't care about. Yes, it's nice to give the team some recognition. No, I still don't care :)
So what's new? Well, there's a roundup of links here, but the thing people are noticing is another RSS extension that allows for ordering of items. If I recall correctly, this was discussed on the Atom list, but I don't think they ever resolved it. About the time of the umpteenth "angels on the head of a pin" discussion, I tuned out. Anyhow - here's the Simple List Extension spec. I'm going to have to have a look see, and see what I'll have to do to deal with this in BottomFeeder.
In Longhorn, it looks like MS is trying to make RSS-centric development easier on the Windows platform. It looks to me like MS has given this some thought - but with Longhorn scheduled to be released sometime during the next millennium, it may not be that relevant.
I like Steve Rubel's writing, but this comment is just... odd:
However, Microsoft needs to be very careful not to push the technology too far so that it only benefits them. It will be interesting to see if the extensions they are planning to add to RSS are truly open to everyone on all platforms (e.g. Linux and Mac) - not just Windows. Otherwise, it could be a repeat of embrace and extend - which got Microsoft into a bit of trouble back in the heyday of the browser wars.
How exactly could a new spec be made Windows specific when we are talking about an XML format? It's tags in a namespace guys, not Windows library code :)
The new list extension MS announced looks pretty easy to deal with - if I wasn't going to be busy with Smalltalk Solutions next week, I'd have an update with support ready in a day or two. I'll plug away at it in spare moments, and should have something out before the end of the week after StS. The cool thing is that Bf already has all the sorting/filtering capabilities this extension requires; all I need to do is capture the meta-data and expose it.
StS 2005 starts on Monday morning - a bunch of us will be around on Saturday and Sunday - we have a semi-organized outing to the theme parks on Saturday and Sunday. We'll be back before 6 on Sunday - the coding contest finals are Sunday night. If you want to join us at the parks this weekend, contact me.
Interesting - Phil Ringnalda says he's going to have a few problems dealing with the new List element MS introduced:
That title element in the cf:sort element is the one with teeth. My SAX parser goes along, notifying me whenever an element is opened, and again when it is closed, and when the channel opens I say $in_channel = true;, and leave it that way until I see an item open. Then, when I see a title element, if $in_channel is true I use its content as the title for the feed, so I'll wind up calling that feed "The title of the item." And since I didn't invent that style of RSS parsing, I'm not going to be the only one getting bit.
Well, I don't think I run into that. I use the VW XML parser to create a document object, and I then walk through that to get the elements of interest. The only thing that causes me difficulty there is my own issues with understanding specs :)
Here's the weekly log scan - time to see what people are looking at, and how. The BottomFeeder downloads - a bit less than last week:
Platform BottomFeeder Downloads Windows 560 Mac 8/9 322 HPUX 314 Sources 312 Linux x86 172 Mac X 148 CE ARM 101 Update 80 Windows98/ME 17 Solaris 13 Linux PPC 9 Linux Sparc 7 SGI 3 AIX 2 CE x86 1
Just under 300 per day - still a good rate. Maybe adding support for the new list stuff will make a difference. I need to have a look at the new MS common feed support, and also at the COM level support for Podcast lists in things like iTunes. I could really use some help on that one though (hint :) ) In any event - the RSS access logs:
Tool Percentage of Accesses BottomFeeder 18.8% Mozilla 17.8% Net News Wire 13.6% Java 5% Safari RSS 5% Other 6% NewsGator 4.3% BlogLines 3.7% SharpReader 3.2% Liferea 2.8% BlogSearch 2.6% Lilina 2.1% Internet Explorer 1.9% Planet Smalltalk 1.8% Feed Reader 1.8% Feed Demon 1.5% MSN Bot 1.4% Feed Tagger 1.4% Magpie 1.3% RSS Bandit 1% Python 1% JetBrains 1% Google Bot 1%
There's a change - Mozilla access is down, and the use of dedicated feed readers is up. That's something of an anomaly - I'll have to see if that holds up. Finally, the accesses to the html blog pages:
Tool Percentage of Accesses Mozilla 52% Internet Explorer 35% Other 4.4% Java 3.2% MSN Bot 2.4% Google Bot 2% Opera 1%
Interesting results with the last set - aggregator access to the HTML pages (never that high, but there) is off the bottom, with Mozilla access still high. Now, as it happens, my pageviews went up this week, so maybe that's it - hard to say without a deeper analysis.
Despite Atom’s technical strengths relative to RSS [2.0], RSS has such momentum in the marketplace today that if the Atom folks came out and tried to bash their advantages around, claiming that RSS is legacy, that RSS sucks, that RSS is somehow closed and proprietary because it wasn’t developed using a community process, they’re going to come out on the loosing side of things. The people who support the Atom approach need to *demonstrate* the advantages of using Atom by deploying it side-by-side with RSS. Demonstrate the technical merit through example rather than evangelization and rhetoric. Show me the code, show me the benefit. Until you do, get used to hearing more and more people talk about RSS.
To which Danny states:
Ok, I’ll stick my neck out on a prediction or two. Some developers are bound to try producing/consuming RSS 2.0 including the various extensions: comments, Creative Commons, Yahoo Media, Microsost Lists. It won’t be easy to use such things in concert without a common language beyond XML syntax. If recent history is anything to go on, these folks will have their eyes glued to RSS 2.0 and blinkers on when it comes to the considerable work done around RDF/RSS 1.0 and Atom (which does have something of an extension mechanism). Expect ball of mud parsers and object models. An extension replacing the ill-specified escaping of content is likely to appear too. Before long, probably within a year, someone will propose an RSS Meta Format specification. By the year 2010 the “simple” RSS fork will have reached the point RSS 1.0 was at in 2000 (but everyone will be using Atom anyway, and no-one will notice).
I'll make a small comment here to Danny - Java and C# just suck compared to Smalltalk. And I mean suck. Technical merit doesn't always win the day, and James makes that point very well in this context.
I'm here at the Wyndham in Orlando, ahead of Smalltalk Solutions. I went to Blizzard Beach with Michael this morning (yes, he finally arrived). I also ran into Giorgio Ferraris, but he had to do some work for a client - he'll likely join us at one of the theme parks tomorrow. Planning to join us? We'll be in the Wyndham lobby around 9, and some of will be having breakfast as early as 8.
Yet the tale is true, at least most of it. Because on June 29, 1905 -- exactly 100 years ago on Wednesday -- Archibald Wright Graham made his lone appearance in the majors.
He never got to hit. Instead, he was left on deck. A late substitute in a lopsided 11-1 win, he played only two innings and there's no proof he ever touched the ball.
"Graham went to right field for New York" was his only mention in the local Evening Telegram's play-by-play account. And, just that fast, the 28-year-old rookie described in the sporting press as being "quick as a flash of moonlight" was gone.
No wonder it took quite a while for his story to get around -- and for author W.P. Kinsella to make Graham such a part of the poetry and romance that celebrate the lore and lure of baseball.
Wow. That movie is one of the flicks that really, really get to me.
We just got back from Magic Kingdom, and now I'm doing last minute prep for the coding contest - which starts in less than 2 hours! I'll have some pictures from the day posted later
Darrell Norton explains why dynamic languages - like Smalltalk - map so much better to the ideal design process:
designers, mentally and at lightning speed, were doing the following things:
- They constructed a mental model of a proposed solution to the problem.
- They mentally executed the model -- in essence, running a simulation on the model—to see if it solved the problem.
- When they found that it didn’t (usually because it was too simple), they played the inadequate model back against those parts of the problem to see where it failed, and enhanced the model in those areas.
- They repeated steps 1-3 until they had a model that appeared to solve the problem.
Now, look at what Benjamin Pollack does when using what he calls REPL in Smalltalk:
- Add or modify a few methods in a couple of classes
- Open up a Workspace (Smalltalk’s REPL) and print out the results of some arbitrary code that tests what you just wrote
- If you hit a bug, you can easily inspect any value in the entire system to find the error
- Once you find it, make the change, massage any “damaged” data back to pristine state by hand using the Workspace, and then resume execution where the breakpoint happened to see whether your fix worked
If you map steps 3 and 4 in the second list to step 3 in the first list, they are almost identical!
That's a very good point - the Smalltalk developer is solving domain problems while the static crowd is handling syntax issues :)
Earlier today, a few of us went over to the Magic Kingdom for part of the day - Blaine Buxton, John McIntosh, Michael Lucas-Smith, Niall Ross, Giorgio Ferraris and I headed over a bit after nine, and hit a few of the rides. We managed to get on Space Mountain, but Thunder Mountain was closed. We hit a few other things - I managed to get the most points on Buzz Lightyear, and we watched the parade. I snapped a few photos as well - Niall and Giorgio headed back early, so they don't appear in any of the shots. Here's a picture of (left to right) Blaine, Michael, and John:
Here's a shot I took of Cinderella's Castle on our way out - it's not that clear (I used Medium Res and a 2x zoom), but that pink shape in the middle is a changing image of looks they've given the castle over the years:
I'll post some pictures of the 3pm parade in the next post up
Here are 4 pictures I snapped of the parade at Magic Kingdom. We watched it from the base of Main Street, looking down towards Cinderella's Castle:
That last one is Belle (from "Beauty and the Beast") waving at the crowd. The kids love that :)
Dare Obasanjo just filed some notes from Gnomedex - I spotted this exchange between Bob Wyman (of PubSub) and an audience member:
A member of the audience responded that he used multiple formats because different aggregators support some formats better than others. Bob Wyman replied that bugs in aggregators should result in putting pressure on RSS aggregator developers to fix them instead of causing confusion to end users by spitting multiple versions of the same feed. Bob then advocated using picking Atom since a lot of lessons had been learned via the IETF process to improve the format. Another audience member mentioned that 95% of his syndication traffic was for his RSS feed not his Atom feed so he knows which format is winning in the market place.
That's about the size of it. Google is pushing Atom via Blogger, but outside of that, it's mostly RSS. You can whine, argue, fuss (whatever) - but that's the reality. In the end though, it doesn't matter that much to end users - most aggregators support all the formats (I certainly do in BottomFeeder), so we are going to end up in a place where users will subscribe, neither knowing nor caring what format they get.
"An interesting article from The Los Angeles Times questions whether readers are still interested in the Harry Potter books. The article wonders if the original fans, now teenagers and young adults, have outgrown the books and if the publishers, Scholastic, have a challenge in trying to keep the series compelling for the original readers who may now heading off to college and jobs." - I can tell you from my perspective that I'm more addicted today then I was a few short years ago. After my oldest daughter read the first three books I had zero interest. Then we took a long road trip and listened to the books on tape, the rest as they say is history. I'm completely addicted to Harry Potter as is my entire family.
I'm with Rob :) At our house, it's all out war over who gets first dibs on each Potter book as they come out :)
Well, what passes for action at a coding contest :) I have a few pictures though - here's Michael hard at work, in the last hour of the contest. Which I suppose I should explain - the final round is to code up a client that can play this game over the net to a server via HTTP. Alan Knight provided a manual GUI (and domain model) for the game - the contest finale is to come up with a client that plays the game against other players through a server. Here's the pic:
This next one is of Kevin Badinger. Andrei Sobchuk had placed third, but was unable to attend the show - we had announced that the top three (actually attending) contestants would be eligible for the final - so here he is:
This last one is of Blaine Buxton, asking Alan Knight a question. Alan came up with the final round contest, and provided the basic implementation that they all started with (as well as the simple server that their entries will play through on Wednesday).
Allen Davis of KSC - the goal is to run Smalltalk unchanged on the JVM. This thing compiles Smalltalk code into Java byte code (.class files).
- Java code from Smalltalk code
- Smalltalk callable from Java
- Java Subclassing from Smalltalk
- Execution in the Java environment
- Full support for Smaltalk blocks
- Support for JITs
- "Do anything in Smalltalk that could be done in Java"
They had to implement a metaclass layer, since Java classes aren't objects - to quote - "polymorphism is completely broken on the Java class side". So a Smalltalk class in this system is not a Java class - it's an instance of a Java class. Going back to the Blue Book, they recreated the same hierarchy of metaclasses that exists in Smalltalk. They had to do this for multiple reasons, not least so that you get real inherited lookup of methods on the class side.
So a few of the hard questions - how do you get performant blocks in this kind of system? One possibility (ugly) is inner classes. There are scope resolutions with respect to variables though - compilers will bark at modifying variables based on where they are declared. So, you could create Context objects to dodge around that issue - this allows values to be changed within the inner class. That gets complicated though.
For blocks defined in a particular method for a class, they defined as methods for that class and use Context objects to get around the issue above. The next problem - type constraints. Allen says that they have gotten around this problem, getting static behavior even within a dynamic environment.What they do is push method implementations up to a common implementor in the inheritance chain, using "synthetic methods" (a feature Java allows, and most tools hide). They didn't do anything with Java interfaces. The common nheritor has a #doesNotUnderstand: that sorts it all out.
There's a good question - what about #perform? Same thing as above - the common inheritor has a #doesNotUnderstand: implementation that sorts it out. In many cases, they can just inline those. They use reflection in other cases and then cache the results to improve performance.
What about exception handling? Here the ST on the JVM approach is using Java handling - so by the time it gets back up to the recovery point, you no longer have the stack (so, no Seaside on this implementation). This is more akin to the VA Smalltalk behavior, rather than the VW/Squeak behavior.
The main thing - they are making the code available under the LGPL (unless someone comes up with a better license to use - the choice of license was a hard question). Full crowd - interested audience for this one. "The code is self documenting" - heh. Questions? Send them to Allen.
9:15 - Thor Raabe of Unaxis, a semiconductor manufacturer based in Switzerland. These guys do wafer production. I'd take a picture of the wafer production cycle, but the glare would make it invisible, I think. They use ControlWorks to control a number of the processes in the manufacturing cycle. So - what do they do with ST?
- Develop and support control system software for automated production
- Development environment - ControlWORKS (Adventa) - currently VW 2.5.x, but it's moving up to VW 7.x
- Shipped their first system in 1996
- Total systems shipped: 400+
- Software team is in 2 locations, 10 developers, 6 support engineers, 2 managers.
Here's a shot of the cycle, highlighting the steps that Unaxis manages - I got this from the StS presentations CD (all of this will be posted after the show)
ControlWORKS comes from Adventa, which spun out of TI - it's a privately held software firm. The software provides:
- An OO model of a machine
- A set of frameworks that can be extended by manufacturers (which is what Unaxis does)
- Very large - approximately 450 packages, 3000 classes, 40,000 methods - i.e., about the size of the VW development environment itself!
It provides a simulator, which is critical given the cost ($5M and up) of actual hardware. They can use the simulator to help build the hardware along the lines of what they need, and the result can serve as a sales demo tool. The code that drives all this is 100% identical - running either the simulator or the hardware. Here's a framework overview:
There are a bunch of screenshots here of the ControlWorks software - here's a picture of one of those - in the picture below, "image" means a Smalltalk image:
One critical thing they can do quickly is come up with new "recipes" for production - this is changing all the time based on the R&D that's happening at the hardware/design level in the production area.
How do they do machine control? They interface down to the hardware using discrete I/O, ethernet, DeviceNet (CAN-bus), serial port access. They have to handle the actual material/machine movement, alarms that get raised by the hardware, etc. They use Finite State Machines for much of this. The framework started with lots of threads, and that made for a lot of thread management code - over the last four years they've switched over to finite state machines. All of this runs under a set of constraints that mirror Asimov's laws -
- Don't hurt any people
- Don't hurt the wafers
- Don't hurt the machines themselves
Finite State Machines:
- Each FSM has its own process
- provides template for behavior
- standardizes code, allowing for better browsing/development/debugging tools
- Provides asynchronous interfaces allowing for interruptible behavior w/o having to manage multiple processes.
- They use Trigger events for alarms
- Requires exception handling in each FSM, rather than one global handler (ironically, I've run into this issue in the post tool based on SwS thread usage)
They rely on reuse - they don't have time to create systems from scratch for each piece of hardware that wanders down the pike. They created configurable policy objects that can get plugged into their modules - see below:
- Small teams matter
- They are adjusting to Store, very used to ENVY
- Very big learning curve in this domain
- Class libraries are huge
- Testing is expensive (due to the hardware costs)
- Finding Smalltalkers with the right (real-time) background
- Perception that Smalltalk is slow (sales issue - not actually a problem)
- Non-Native UI widgets
- "Smalltalk isn't mainstream"
- Smalltalk enables a high degree of reuse
- Generic framework abstractions
- Smalltalk makes it easier to focus on the problem rather than language issues
- Debugging is much, much easier without having to go through a recompile and restart - due to the expense and difficulty of getting to the same state.
- Unaxis is pleased with VW and ControlWORKS, and has no intention of moving off
Interesting tidbit - Java may run on the phones, but the chips that run the phones are built with Smalltalk :)
Rajesh Jayaprakash makes a discovery about Smalltalk after plowing through an initial hurdle:
I am glad that I went ahead with Smalltalk because I am pretty sure the same effort in Java would have taken me much longer. The ease and benefit of incremental coding and testing (the Workspace really comes in handy for this) was really striking.
Once you discover this, everything else is just painful...
Looks like the Supreme Court has no clue about the "fair use" concept:
In a decision announced by Justice David H. Souter, the Court said: "We hold that one who distributes a device with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, is liable for the resulting acts of infringement by third parties" -- that is, computer users using free downloading software.
By this "reasoning", the VCR is illegal. What utter Morons.
10: 30 am - Eric Evans on Domain Driven Design. Here's Alan Knight introducing Eric:
And here's Eric starting his talk:
Domain: the critical complexity of most recent projects is in understanding the business domain itself. Note: This isn't true of all projects - there are technically oriented projects where the challenge is simply to overcome a technical issue (scaling, etc). However, most projects don't live there (contrary to what your larger companies and consulting firms would have you believe).
We tackle complexity with models - "when I say model I don't mean a UML model". Eric popped a couple of maps up as an example - an ancient China map, showing China at the center, and everything else on the periphery. Then a modern map, with North America at the center. The point being, that maps are models that serve a purpose (the importance of China, or the need to navigate from London to the new world) - and they then get picked up as "good enough" for other purposes.
"A model not reflected in the code is irrelevant". It doesn't need to be as realistic as possible so long as it serves that purpose.
His example is a cargo container routing system - and the model he popped up is a common one (especially with non-Smalltalk audiences) that starts with the database and works back from there - rather than starting with a domain model and dealing with the business users. So:
"A cargo makes a series of stops. At each stop it is unloaded from a transport and loaded onto another."
So, after taking to a business person, you end up with a few choices - in this case, are we dealing with stops or legs? This is the kind of choice you get confronted with in any business project, and it's not necessarily clear which is better (in the cosmic sense). What you'll end up with, if you analyze it, is the one that works better for you - you need to choose concrete reference scenarios rather than abstract, theoretical exercises. In the example (cargo shipping), Eric pulled up a map to show the route of a block from LA to Hong Kong. No help there - either model maps to this well enough.
What about re-routing in transit? That's also a viable scenario. Say the customer calls and says "it turns out that I want one of my containers to go to Seattle instead (or Dallas)". Here we have a distinct difference between the two models. With a stop based model we can add itineraries as we go, by appending a new itinerary after truncating the old one. What about the leg based model? The re-route seems easier than the other one, so this scenario tips that way. In general, you need to examine more and score them. In general, you select for the models that make the hard problems easier (the simple ones can be solved either way).
You use models then as a reference for determining what models make your most challenging scenarios easier to solve. We need tools that let us express models without getting bogged down in technical detail. Many people try to make that equivalent to: "Need tools that allow less skilled developers to use parts made by smarter people".
That latter theory is what drives Java, .NET, and the entire mainstream. When I attended this talk at ot2004, that was Joshua Bloch's entire explanation for API design - he posited a pyramid, where most developers live at the bottom. In fact, when I spoke to him afterwards, he told me point blank that Java developers weren't smart enough to use tools like Smalltalk. This is the mindset of the people delivering tools to the mainstream.
Back from my min-rant - Eric doesn't have a lot of patience for that, or for visual programming, or for UML driven theories that try to raise the abstraction level up. Language is our fundamental abstraction tool - and Smalltalk is one of the best languages for expressing a model. Back when Eric started with Smalltalk in the 80's, he figured that we would have something better than Smalltalk by now - and instead, we have Java.
Ok - what are Eric's currently favorite modeling tools?
- Whiteboard (with digital camera) - post results to a Wiki. Or the smartboards that can push directly to the network
- Smalltalk browser
- Unit tests
- Mouths and Ears
Drive the Design from the Model. Models are distilled knowledge, not knowledge gleaned from some over-arching upfront analysis. Also - Smalltalk code is easier to manipulate and change after the fact, which is important - because we never get it all right the first time. [ed] - this is one of the reasons that I think "final" is such a terribly bad idea - it makes an early assertion of perfect correctness.
many problems arise when the model does not match the customer's way of thinking. A bigger problem is what Eric calls context matching. He showed a picture of the fastest human powered rowing - an 8 team boat (the kind used in competitions). The reason that larger teams aren't slower is the fact that people tend to get out of synch with each other. The same thing happens in software. On large projects, there are always multiple models.
You'll get this problem even on smaller teams - it's not unsolvable. Problems arise when teams try to come up with the "one true" model for everything (wherein everyone works with a sub-optimal design for their part of the problem. With multiple models, there is a translation cost.
There are many teams that live in what you can call an upstream/downstream state - one team depends on the work of another, and is actually - to a large extent - controlled by it. To get better coordination you need trust and communication (picture a relay race, where the runner in front runs fast, holds their hand back, and relies on the prior runner to place the baton in their hand). You need to build up a complex "anti-corruption" layer only if you don't trust the upstream team.
Important: Map the contexts as they are, not as you wish them to be. For more information:
It's the after lunch slump (2 pm), so of course I'm attending the talk that will require attention - Daniel Poon's talk on number crunching. So: (they are using what they started with - VSE)
What does Smalltalk have to do with Numerically intensive tasks?
- Conventional Wisdom - slow, out of date
- Daniel says - look at what we do
Romax has been building in Smalltalk since 1994, and they think that Smalltalk lets them model mechanical behavior in ways that other technologies would not allow. Their customers include some of the biggest manufacturers (looks like a lot of vehicular/parts corps). From their website, they specialize in gearbox design. Their tools model various shaft arrangements - parallel, vertical, planetary (those are apparently technical descriptions).
F (Force) = k (stiffness) * x (deflection). They are solving for x. Given:
- Stiffness (stiffness of components)
- Forces (produced by engine, transmitted by the gearbox)
- Solve for Deflection (how the design will distort under use)
They do what's called VPD (Virtual Product Development). Typical transmission design (with real models) can take 3-4 years, and costs money for the parts. They can reduce that to 12-18 months using simulations.
- Customers always asking for more complex simulations
- That puts greater demands on performance
- The market demands shorter and shorter development cycles
- Which leads to Smalltalk
The main advantage they get from Smalltalk is immediate compilation and late binding. Late binding allows testing even when the system is broken. This gives them a step change in their programming style. Things they make use of?
- Double Dispatch
- Bouncing GUI code to test behavior immediately
- Extending the language/libraries as needed
- No need for multiple callbacks
- Resumable exceptions, the ability to customize handling of any and all exceptions
Daniel thinks Smalltalk could be widely accepted in the technical market. The market is huge and growing. Smalltalk is designed for the analysts own use - and Smalltalk has fundamental goodness for technical computing:
- Arbitrary length integers and fractions
- BlockClosures (pass equations into solvers)
- "Immediate" mode (doIt)
There are obstacles though - you'll need a Smalltalk coach for things like syntax (operator precedence, array syntax), lack of native solvers, floating point performance, and mixed language support. So on Floating point - Smalltalk is 70x slower than Fortran. So they use a layered architecture -
- product Model in Smalltalk
- Engineering calcs done in Fortran
- profiling shows that 60% of the time is spent on shuttling data back and forth - this is difficult to optimize
What they do is write everything Smalltalk - once it works, they profile and move critical bottlenecks to Fortran. The layered architecture really needs to be designed by the same team - at the same time - so that they mesh properly. What they did was create a single cross functional team, and instituted pair programming between the Smalltalk team and the Fortran team. This approach helped both with old hands and newbies - the new developers rapidly picked up domain expertise this way. [ed] - this is an old model - the master/apprentice thing. They've been doing this pairing approach for four years now.
There are terms for the two possible development modes - seperate teams (Chassis/Body), and the unified team described above (Monocoque). Why use the latter? The increasing demand for complex analysis pretty much requires it.
Bottom line - they think that Smalltalk gives them a competitive advantage over the other guys who use "mainstream" stuff. What could the Smalltalk community do to help? Take technical programming more seriously. Here's a picture of Daniel giving his talk:
2:45 - Dan Antion of American Nuclear Insurance. Here he is:
He's pointing out that he discovered this rather than inventing it - he's sharing his experience and demonstrating their results.
They had a limited need for application protection, a greater need for tracking - which versions are running, and where they are. They needed a distributed, Smalltalk solution. The lessons they learned - Choose your enemy:
- Casual Sharing - you might be able to stop this
- Hacking of shareware or time bombs - harder to stop
- Cracking and distributing keys - you won't stop this without a large effort/resources
They use a number of tactics:
- Difficult to guess elements
- Transaction Information
- Version Information
The response depends on the threat level and risk of loss. They use a set of numbers (including base 26 primes, version tags, etc) to create the designator.
- First - base 36 large prime, selected from a table based on the serial number. They restrict the choices based on an algorithm. This results in a 5 character number.
- Next is the product code, can include some significance (where it was released, etc). # characters
- Next is a 4 character Nth prime generated on the fly (based on the serial number) - this could be anything
- Next is a one character number or code
- Next is a 5 character alpha-numeric from the username and serial number. It could fit any kind of mask pattern
- Finally, a 3 character minor version number - probably useful for the "About" box"
- Last step - they obfuscate it some to mix it up. They rearrange it (could be a shift, hash, etc).
They made this modular so that it could be modified over time, to allow for different sorts of keys for different releases, etc. Their primary purpose is tracking. Once nice thing is that automated support requests can include the key, so that support can tell where it came from (supported rev, demo, etc, etc). One simple technique to frustrate brute force attacks on a validation server (not that they do this) - insert a delay in the validation to hinder brute force attacks.
Very important - don't annoy real customers. Respond appropriately, but make sure you find out what's happening. Actually contact the user.
4:00 - Vassili Bykov on Pollock, APIs, and the toolset. His usability example is last year's Sony Dream Machine (which was in the rooms at last year's StS). Apparently, this thing is a usability nightmare requiring multiple button pushes to make things happen (in utterly inexplicable ways). He points out that the "API" to this device is awful :) Here's Vassili:
Here's a programming example:
specifiesPixelSize "Answer whether the font cares about its size" ^pixelSize notNil pixelSize "Answer the receiver's pixel size" ^pixelSize == nil ifTrue:  ifFalse: [pixelSize]
That's a thing of beauty :) Vassili: "Everything I needed to know about framework design I learned when I was 5". He gives an example of stacking blocks. "Simplicity takes work. Complexity happens". So what's cool about Pollock? Intelligently stupid widgets (as opposed to Stupidly intelligent :) ) So - on to demos. My camera phone won't really capture these, so no pics...
One of the big improvements coming is in layout of widgets - either with respect to the pane they are in, or with respect to each other. You can do some of this in Wrapper now (see this post), but Pollock and its tools are going to be a step up, making it possible to specify various layout options in a more obvious fashion.
Now he's talking about tooltips - doing these for Wrapper was real work, involving a 4 state finite state machine. There are 4 states - cool (start), armed (0.5s delay), reaper (tear down), and warm. The warm state pops a tooltip with no delay (i.e., after you get one, just move the mouse along a toolbar to see that). In the current implementation, there is one state machine for the entire system. The Pollock state machine is the same, but with a much cleaner API.
The entry assistant (auto-completion in text entry fields) is simpler as well. The Wrapper implementation requires an additional process (with the synchronization problems that entails) - in Pollock, it's all part of the keyboard handling process, so it "just works" (and is pluggable). He's also demonstrating Intellisense type help, which will appear in the Pollock tools. So much for the claim that "you need static typing" for that :)
Ahh - now he's talking about Splash - the planned GUI builder for Pollock. There's now an extra piece he's calling "Scallops" (fix a bug in Pollock and we'll explain that, he says) - it's the common bits that go between the Pollock framework and the Splash builder that would have use beyond the builder (specs, etc). One of the reasons for seperating this out is to more easily allow for programmatic (i.e., non-spec driven) GUI creation. Pollock will support both modes. The nice thing is, the tools will support moving back and forth - you can generate code from the spec, or an XML spec from the UI Spec - [ed] - I can imagine some Software With Style value adds there :)
Greg Bonadies - "transition manager" - just reiterated the schedule - EOL for VAST (from IBM's side) in April 2006. So, what is their answer to "Why?"
- Aligning with IBM's AD strategy (Eclipse, WebSphere)
- Protect VAST investments
- Allow sufficient time to transition
- Enable Transition strategy, tools, partners
- Provide extended support
- Define bridging and migration-readiness strategy
- Engage IBM services and partner expertise
"From a portfolio perspective, we are responding to the market". So, the options - All the paths lead to J2EE and WebSphere - you too can downgrade and become just as ineffective as your competition. I love the way they call it "modernization", btw. It has a marketing department approved kind of sound associated with it. Heh- Bruce Badger asked about .NET, and Greg said sure, you can move there too. In general, they are touting J2EE, Rational Rose tools, and Eclipse (Look, Eclipse is free! Never mind those WebSphere licenses behind the curtain).
"Sometimes technologies feel the weight of change around them, or their failure to move" - I could be snarky about that, but hey - fill in your own comment there :) They are offering an additional two years of support after EOS (End of Service) for customers who want it. This is being delivered through the existing support organization and their field service people. Now it's on to partners:
Synchrony Systems and CSC Solution Services, who they will be using to migrate people over to WebSphere and Java. He got to Instantiations last, which is who is providing ongoing support/development for VA Smalltalk. His real emphasis is on "Transitioning and Modernizing" with Synchrony and CSC (read: Move to WebSphere).
So - Instantiations gets VA licensed to them, allowing derivative works from the current product. "That might be appropriate for some customers" - boy, is he ever playing down any desire to stay with Smalltalk. The IP has not been transferred to Instantiations, and there are a few things that they will not be allowed to ship. Mike Taylor (Instantiations) said that it mostly involved an inability to sub-license or open source the product. Eric Clayberg (Instantiations) pointed out that the Smalltalkers left at IBM went out of their way to make this all happen - would have been easier on them career-wise to just let it die.
A positive note from John O'Keefe - he's pleased that Instantiations has picked up the codebase and is willing to work with it.
Synchrony - supposedly, 40+ successful migrations. Odd that the website only has 2, and those projects don't list any recent details. I rather suspect that most of those are Smalltalk to Smalltalk, and mostly involve VSE to VA. "These guys are *cough* Smalltalk bigots *cough* deep down".
And CSC - they bring the J2EE migration gnomes along.
Meanwhile - if you want actual modernization - go download Cincom Smalltalk, and see what it really looks like.
James Gosling inadvertently mentions one of the reasons Sun loses money while IBM rakes it in:
Then there was all the stuff about open sourcing of our app server, a project internally named GlassFish. It's all out there at glassfish.dev.java.net. We've been pricing the binaries at $0 for quite a while, now all of the source is out there for anyone to grab and play with. It'll be the place where we do our work on the evolution of Java EE.
IBM being there was wonderful: the contract negotiations had gone on for quite a while, and resolved to everyone's satisfaction. They've been great supporters for years and I'm very happy to have all the details clear once again.
Price for the IBM Application Server (last I checked, the most popular in the Java space) - big bucks. Price for the Sun entry in that space - $0.
Martin Kobetic, 8:30 am. We are talking about Opentalk, starting with Multicasting. Works in an IP range, using UDP. Range for multicasting is normally within a single network, but it can be extended via a router that can forward IGMP, ttl. Here's Martin:
There's code in VW that makes it easy to set up for sending or receiving messages from a multicast group. To raise this up a level from sockets (Martin just ran us through a set of slides with the registration code), there's Opentalk-Groups, which puts in an object layer. A group:
- brokers running on the same port
- brokers join the same mcast address
- receivers exported under the same OID (Object ID)
- group proxy #(mcast-address, port, OID)
- Remote Group Request - STSTOneWayRequest
To set all that up, you create a broker with the appropriate parameters (again, there's code up there that I can't type fast enough :) ). Basically, you set up a broker and advertise yourself to the mcast group. Once that's done, you can start broadcasting messages, like so:
group := broker groupById: #group. group show: 'Hello World!'.
Heh - no demo is complete without a debugger popping - Martin's first crack at showing a chat system had one. Simple fix and a multi-person chat - without a server - was up. Next - we are going to participate in a grid demo. Best example of a well known grid: SETI@Home. It handles:
- resource discovery
- resource configuration
- task distribution
- result collection
The demo? Code breaking of RC4_40_MD5, using a brute force methodology but with randomly selected ranges, ranges searched sequentially, and looking for a known pattern ('GET/'). I can't get my system to join, but 5 other clients have hooked up. The thing to keep in mind here is that we are - with 5 clients on the grid - breaking a 24 bit key.
The framework is pretty simple - there's a controller managing the entire task - distributes tasks and collects results. Then there are the drones, which get sent tasks, execute them, and send back results. I may well post the code for this demo when I get some time later - it was pretty cool.
9:15 (A little later actually - there's some initial set up to be done) - Charles Monteiro is about to demonstrate "Opentalk Matrix" - he's got multi-monitor at home, and that's causing a problem with the screen display. The joys of A/V :). Here's Charles fighting with his laptop:
What we have up now is a peer to peer technology demo. Somewhat similar to the grid idea. Charles is the guy behind the NYC Smalltalk User's Group - I've been up there to speak numerous times.
So - Opentalk fits pretty nicely for doing p2p stuff. He's setting up a three node p2p setup in here. The screen for sharing content looks like this:
Basically, you can register stuff as available to grab, and browse the p2p network for content that is available to grab. The three system demo is working here, and Charles is pushing content between systems. The demo worked, but there were network configuration issues (it's really hard to set up a network demo on the fly given firewall installations and Windows configurations differences).
The basic thing is this - OpentalkMatrix can do some pretty cool things, including downloading of VW parcels with all pre-reqs (including non-Smalltalk pre-reqs, such as image files, etc). I've seen this demo done in NYC, and it looks pretty cool when stuff is set up properly. For parcels and supporting resources, OTM sets up the proper relative path.
What else? There are configuration options for things security, resource support, pre-reqs, comments, and keywords. In terms of security, there's not much more than a pluggable area. Charles plans to add more.
He's created a bootstrap environment for an SRE (Smalltalk Runtime Environment) akin to Java web start. Charles is hoping to get some "well known" peers set up to bootstrap a network. There's support for having peers exchange index information in order to speed up searches, as it can centralize searches to the "super peers". This does require that information be kept up to date.
Combination to Create Ideal Partner for Customers and Systems Integrators Focused on Service Oriented Architectures (SOA)
SANTA CLARA, CALIF. and MONROVIA CALIF. -- June 28, 2005 - Sun Microsystems, Inc. (NASDAQ: SUNW) and SeeBeyond Technology Corporation (NASDAQ: SBYN) today announced that they have entered into a definitive agreement for Sun to acquire SeeBeyond. The acquisition of SeeBeyond, a leader in enterprise integration, with trailing 12 month revenues of approximately $167 million and 2,000 customers worldwide, will allow Sun to create what it believes will be the industry's most complete offering for the development, deployment and management of enterprise applications and Service Oriented Architectures (SOA).
They spent nearly $400 M on that. I'm sure the analysts will love it, but go find one and ask them this: "Please give me a concise definition of SOA". Then ask them how this acquisition helps :) At this point, I distrust any announcement that has the term "SOA" anywhere in it...
AMD filed an antitrust complaint against Intel for Intel's monopolistic and anticompetitive practices. In AMD's official complaint they cite many instances of Intel using its larger size and resources to push AMD out of the market. Examples include Dell (of course), IBM, Sony, Toshiba, HP, NEC, Fujitsu, EMachines, [...]
Jim Robertson had a writeup of the talk here . One interesting tidbit he didn't mention was a question about how much of the world's semiconductor production has been processed by machines running Smalltalk. His answer was that it was probably around 100%. Unaxis makes three different kinds of machines, and for one type (Mask etching, I believe) they have around 85-90% market share. And they're just one of Adventa's customers for ControlWorks. Other places have already talked about e.g. AMD's use of ControlWorks.
So - Java may run on the phone you have, but the chips running it were built with Smalltalk. A more important difference - Sun makes approximately $0 for the Java penetration there, while we actually make money from the Smalltalk use.
I just love this from Spielberg:
Oscar-winning director STEVEN SPIELBERG is baffled that fewer UFO sightings are made now than were made twenty years ago - because the technology to record would-be aliens is so commonplace today.
The 59-year-old film-maker has made a string of alien-themed movies - CLOSE ENCOUNTERS OF THE THIRD KIND, ET: THE EXTRA-TERRESTRIAL and WAR OF THE WORLDS - and is disappointed it seems he'll never get the chance to see evidence of a UFO himself.
What that means is that the Air Force is being a lot more careful with their test flights. Sheesh.
This is kind of interesting - last night's BOF was hosted by Greg Bonadies, who's the "Transition Manager" at IBM - this is the same set of slides, but hosted by John O'Keefe (IBM) and Eric Clayberg (Instantiations). One way to look at that is that Greg was giving the official IBM line, whether he liked it or not - now John has a chance to introduce Eric and let him talk to their future plans. Here's a picture of Eric and John, just before the talk:
Yep - that's it - John introduced the talk as "VA Smalltalk: going forward". Different message wrapper than last night :) First up - John explaining where IBM is, and what's going on at their end. Interesting - EOS for VAST is April next year, except for Z/OS (mainframe VA). That will stay supported. Makes sense - the customers who have that are likely big ones.
Reiteration of why IBM is doing this - Smalltalk doesn't fit in with their current development language/platform plans, and IBM is trying to get rid of products that don't fit. John is making sure to point out that it's a better idea to stay with Smalltalk (i.e., Instantiations) than to do a migration (i.e., Synchrony/CSC). That's a different spin than last night. Again - same slides, same information - different motivation. Another point difference - John is pointing out that the "migration" tools that Synchrony has are useful for dealing with Smalltalk, while staying in Smalltalk.
Bottom line - this is a much, much better message for VA users than what they heard last night, even though all the information is identical.
Ok - on to Eric, and the Instantiations plans for VA. Heh - interesting start - rocket launch with a humorous description of position. I can't possibly relay how amusing this is :)
Eric's bio (most of my readers likely know this) - saw Smalltalk in 1986, started serious work in 1991, helped found (the original ObjectShare). Went through PPD, helped found Instantiations. Has been a partner with IBM on VAST and Eclipse (et. al.) since then. In Smalltalk, best known for VA Assist and WindowBuilder Pro (as well as various GUI add ons). They sell a similar suite of stuff for Java - you can get the full rundown on that over on their website.
Important difference in point - in the transition strategy, Eric is making the point that they don't want people to move off VA - they want to help them stay on it. And what is the new VA going to look like? Current VAST, plus VA Assist, WidketKit/Controls and GF/ST. The list there is VA Smalltalk 7.0, due out in July. GF/ST will be delivered as a goodie.
- Finish ANSI support
- More enhancement of IDE
- More enhancements to Envy/QA
- Integrate the RB
- Support for more Windows stuff
- Enhance the web stuff (some)
- additional migration readiness stuff
- Longhorn support (Heh - that gives them a window, based on the MS schedule)
- More WS* support
- Investigate Namespace support
- 64 bit VMs
The migration readiness stuff - SMT tools from Synchrony. Everyone says this stuff is great, but have a look here. Two success stories, from 1995 and 1998. Both are VSE to VA stories, not a word about the story that Greg was pitching - Smalltalk to Java. Not a confidence builder, if you are insane enough to want to go that way. I'd advise more talk about Instantiations, and less (lots less) about that stuff. Eric went through pricing - that's on their website as well, just follow the link up at the top of this post.
And now he's running a set of demos on VA with the additions being added. Can't say I have a lot of experience with VA, but I did download a copy in order to look at submissions to the coding contest. The browser Eric is showing certainly looks better than the stock one I dealt with. The tools that are being bundled with VA certainly provide a much needed facelift.
Q&A, and the inevitable question: Can someone release Envy for VW? Instantiations did not get the code for that. Instantiations isn't about to do new development for that - 3-4 man years of development, and they aren't going to do it on spec.
Another one - VA on Mac? They don't sound positive on that either. They figure that it's a couple man years of effort to get there. Sounds like no.
2 pm, post lunchtime slump - time for Colin Putney to tell us about Monticello (version 2), a source code control system for Squeak. Here's Colin getting ready to start:
When they started Monticello, they realized that typical version control systems wasn't what they needed for their purposes. Merging was crucial, because - given the nature of the Squeak community - there's a big need to merge code from disparate sources. The first rev of Monticello didn't actually do a lot more than merges.
Colin is discussing the hard problem of merging branches of code, and the kinds of approaches that are possible. The problem gets harder, of course, as the branches diverge over time. They took an approach of recording the ancestry of methods over time so that they can merge at the method level in an image, rather than at the package level.
A Smalltalk specific issue for a version control system - how to update (safely) a running system. In Store, you can run into this issue if you save your package as source (rather than binary), and then load a package from PostGreSQL that modifies sockets. Whoops - the PostGreSQL connect uses sockets. Solution - save the package binary. The better answer is one that Monticello is moving to, and Store is also moving to: compile the code in a sandbox, and then do an atomic load.
They ran into the problem due to some performance issues inherent in the way they were versioning code. The basic stuff -
- Elements (code artifacts)
- Versions (of elements)
- Slice (A collection of elements)
Up now: The team programming panel. Eric Clayberg moderating, with Colin Putney, Niall Ross, and Bob Westergaard on the panel. The systems being discussed will be ENVY, Store, and Monticello. Each panelist has about 10 minutes to talk, followed by discussion. A few questions from Eric - one interesting thing is that most of the people in the room are working on teams of 10-20, a few bigger, a few smaller.
First up: Niall on ENVY. His first reaction to ENVY would have been better had he started with VA Assist. Assumption (correct, as it happens) - we all know what it is, how it works (etc). Small footprint, fairly easy to set up. At some level, you ran into the same divide you do with the VM/VI - you hit the C layer and can do nothing - and since the DB is proprietary, you can't get at it. Doesn't think that the version artifacts and system was immediately obvious. On the other hand, Store could benefit from having a config map equivalent. The base UI for configuration maps - appallling - especially in VW 5i.
The component ownership model - probably seemed like a good idea at the time. The existence of tools (like one Eric demonstrated) where you can become other users) is so common as to illustrate a problem inherent in the model. It tries to enforce a model of work (whereby the owner actually integrates) is one he's never seen in the field. Everyone always hacks ENVY to allow users to become anyone.
He likes the ability to export DAT files and have them remember where they came from and what they are [ed] - but.... if I publish a parcel with DB info kept, it does do that. At least mostly).
The raw toolset is very bad at tracking records. The future? Still thinks some people would like ENVY for VW. Apparently (pace James Foster), Dolphin has an ENVY-like third party tool.
Problems: Not good for remote work (chatty protocol). Always connected model is both good and bad. refactoring can be more painful given the ownership model, and the tools show their age (base tools). Lack of a merge tool, and the public/private divide is odd.
Next: Colin Putney, talking about Monticello. For some details, see the previous post. Monticello came out of a Seaside project with Avi, where they desperately needed tools (there weren't any for Squeak then).
With a versioning tool, you are trying to capture two things: Where you are now, and how you got there. Many tools impose a mode of work, and (for instance), ENVY's model wasn't appropriate for the Squeak community. In that world, you can't rely on any particular model, you have to take what you get and be grateful for it :)
Monticello is above all a merging tool, which reflects the usage model outlined above. At this point, most Squeakers use it, and the 3.9 distribution will be developed with it. The further development is really oriented towards not imposing a process model.
Next up: Bob Westergaard, on Store. There's a fair bit of history here - it goes back to Bernstein, an Eagle project "back in the day". The basic artifact is the package, with Bundles above that, where bundles can contain one or more packages or other bundles. The back end is an RDBMS. We support the major ones, and there are a bunch of community provided back ends.
Store has users, who map to DB users. Store is both loadable and unloadable, and you can develop disconnected. Store has a concept of Blessing Levels (names for published versions). Packages/Bundles can be stored binary (see the previous post again).
The user model is integrated into the existing browser via menu picks, etc. The old (pre RB) browsers are still around for when you browse the DB - that's an artifact of ongoing work which will repair that. Store really lacks a configuration map equivalent, and that's a real problem. We are aware of that, and we know that customers are rolling their own solutions. Another problem - a blown load can take out an image, forcing a restart. That should be fixed in 7.4 via shadow (sandbox) compilation.
Envy for VW 7.x?
Niall: It's a political/legal problem, not a technical one.
About Store - overrides are great. When you have multiple overrides in an image, which one reverts?
Bob: With parcels, they restored in order, but that's broken right now. It will be fixed for 7.4.
What about class versions in Store? We want that, not just package level
Store's model really doesn't support that, it's just different than ENVY
Eliot: That was a design decision
What commonalities are there between the various Smalltalk systems in this area? They all realize that method level tracking is important, and they all integrate into the environment. Others?
Colin: The lowest "unit of work" in the Smaltalk systems goes down to the method/class level - that's very, very different than the mainstream. The mainstream simply does not get the notion of diving down to that level instead of "the file". Integration with the system really begins at the change level.
Niall: The other thing that differs is the Smalltalk notion that everything is open (not true all the way down in ENVY). This means that users can write/modify tools against the system.
Harking to the keynote on modeling - on a scale of 1 to 100, how would you rate these tools as appropriately modeling workflow?
Niall: With regards to ENVY, ownership model awful, versioning too rigid (likes blessing levels). Otherwise not too bad - overall 70-75. Nothing you would scream about other than the ownership model.
Colin: The design of Monticello really followed the usage model in the Squeak community. Smalltalk is all about live objects, so versioning in and of itself introduces a divide - one which you need to be careful around. A number? 75-80. Pretty good, but room to improve
Bob: Store has some problems with respect to its model. As to a number? About 50. A fair bit of that is based on the legacy model we have (from the early 90's)
Georg Heeg, ObjectStudio integrated inside VW. This is an ongoing project, being doen both by Heeg and the Cincom Smalltalk engineering team. History: Cincom purchased ObjectStudio in 1994-1996, and VW later in 1999. Since then, OST customers have wanted many of the same features that exist in VW. Here's Georg:
VW goes back (as does Squeak) to Smalltalk-80 (and predecessors) at PARC. The image is a direct descendant of the original images at PARC (as are all the objects). ObjectStudio was developed as an "Enterprise Object-Oriented Development Environment", called Enfin. ObjectStudio can be bootstrapped any time. VW is fast, and has a solid meta-model. OST is oriented towards client side, enterprise development.
OST customers really want the speed of VW, as well as the tools. They really like the Enterprise integration tools in OST.
It's so commonplace it hurts: A press conference is called. The media is alerted. The top executives gather for much backslapping and multisyllabic descriptions of the synergistic opportunities abounding in this, a fresh new partnership. There's a champagne toast and then the most extraordinary thing happens...nothing! Nothing at all.
Jigsaw, many industry mergers, even a prior attempt to push the VW VM under OST (The HPSOS project). This time, the project was started without promoting it ahead of time to customers, and instead starting with a proof of concept modeling attempt. The idea: Model ObjectStudio in VisualWorks.
- Use Meta Modeling
- Use all reflection capabilities
Both OSt and VW live in the same image. Both share the same kernel and base classes. This allows for mixing and matching.
Heh - the first step started when Georg had a case of laryngitis, and couldn't speak for a week. Thus was started this project with a basic proof of concept. At that point:
- Smalltalk worked
- UI did not
- primitives did not
So, the next step was to have an intern take a swing at doing a DLL that would implement the MFC functions that are currently called from the OST DLL. He took that one function at a time. Over time, it started to work. The plan was to take it slowly, and not modify the VW VM until it was absolutely required. The things that might require speeding up would help all - OST and VW.
The issue - there are 450 MFC primitives, so doing one primitive per day was going to be really slow. So that approach would be way, way too slow - stopped that in January 2005. Instead - take the entire OST C/C++ codebase and make that a callable DLL. There is a pre-alpha ready, but it needs major shake-out work.
So OST is embedded in a single namespace, and it shares most of the VW base. Most OST classes are subclasses (with the requisite differences) of VW classes. There were some adaptations required - PoolDictionaries and Globals move to namespaces (as happened from VW 3 to VW 5i).
Also required - special readers for pulling in OST code, based on the code storage mechanism that OST uses. As well - a special parser, since OST syntax is slightly different. Some semantic differences in the libraries - #at:, #at:put: behave differently (in terms of what they return). So, the implementation substitutes OST specific methods in based on the sender. This technique has been used wherever necessary. The list is not small; there are 40+ of those now.
Another difference - OST has a thin border between Smalltalk and C; they call back and forth all the time. This is largely because OST is interpreted (no JIT), and is thus up to 30x slower than VW in most respect. There are 5 ways to call:
- Direct primitive
- Numbered primitives
- Named primitives
- Module/ENFINModule - programmatic creation of interface methods
- ExternalProcedures - programmatic creation of interfaces with C datatypes
Introduced a VW wrapper - uses regular VW DLLCC. And... There's natice widgets in this project, using MFC. Callbacks come back to VW. So - we can get native widgets now (on Windows).
Class Proxies - it works, but via file-in (so it's slower). Application loading also works, but again, is slow. However - an awful lot of this is due to refresh requests to the RB. A much smaller (but significant) slow down is from disk flushes (for the change file). Other issues in the speed of callbacks (Smalltalk/C)
So - the idea is to make it work, then - afterwards - make it fast. There are still OST packages to deal with (Modeling tool, Database stuff). The plan is to have a Technology Preview (pre-alpha) this winter. We hope to have product by the 2006 major release (winter 2006). Ok - and now a demo of what's there now. He started a stock VW image (Seemingly) - with an additional menu pick - "Start ObjectStudio". The ObjectStudio windows are using native widgets. It's still rough - you get exceptions from time to time.
Final presentation of the day - Rob Gayvert - wxSqueak. This project combines Squeak and the wxWidget set. This is a blend of wxWidgets and Squeak - it's Open Source, and brings native widgets to Squeak. Runs on win32, OS X, and Linux/GTK. Current version: 0.4.1, using wxWidgets 2.6.1 and Squeak 3.8. Here's Rob:
So, what's the motivation? The Squeak UI is cool, but a native UI is essential for many situations. It leverages an existing library (wxWidgets) - it's already been wrapped by other languages. Also, Rob has some experience with wxWidgets. The goal is similar to the goal for Chagall (native on Pollock) - native widgets, portable image. He also wants to be as minimally invasive to Squeak as possible. Ideally, provide a VM level plugin (not quite possible). As well, preserve the API style of wxWidgets.
What is wxWidgets? Cross platform C++ toolkit (goes beyond GUI). Has bindings for multiple languages (wxPython, wxRuby, wxPerl...). It's shipping now with OS X, and has been around awhile.
Challenges? Dueling event loops (wxWidgets, Squeak). Large API (400 classes, 3000 methods). Both Squeak and wxWidgets are fast moving targets. There are a lot of constants, and some vary by platform. Needs synchronous callbacks for event handlers and virtual method overrides. One of the big jobs was a Smalltalk to C++ object mapping. Other things:
- Squeak process polls a primitive looking for wxEvents every 5 ms
- synchronous callback to squeak may happen
- win32 - need to restrict ioProcessEvents
- OS X - need to single thread the event loop
- Linux - no changes, but slow (not responsive enough)
The plugin generator is Squeak based (not SWIG). At the Smalltalk level, he's done a fair bit of work to make the API simple to use for Smalltalkers, by including a bunch ofcenverter/helper functions to deal with C++ interfacing issues. There are around 2700 constants, mostly enums. These are loaded at startup to handle platform dependencies.
The event handling for wxWidgets has to be synchronous (which is different than normal Squeak). Had to allow event stacking because of that. Required help from one of the Squeak VM guys for parts of that.
Generic callbacks: Used for C++ virtual methods that may be overridden in Squeak. There's interest in this stuff - other Squeakers are working with it and extending it. Heh - looks like they'll get UI specs - wxWidgets is going to an XML representation for that. He's hoping to have it all production ready for Squeak 4.0. Unicode and Custom controls will come along the way.
I'm heading over to the Tuesday night event - we are formally announcing our services partnership with KSC. It had to be moved indoors due to the atrocious weather - we've had two days of pretty constant rain or threat of rain. The burgers should be good though, and a crowd of interested people will be there.
Apparently, Sun's got some truly brilliant people in their marketing group. Just look at what they are giving away as promotions at Java One:
Condoms. I was stunned. Condoms, with a Java logo ... given away like candy in a bowel. Right there on the give-away table at the joint community celebration, with Duke in tow and a birthday cake. Condoms. What were they thinking? Are the marketing powers at Sun truthfully that obtuse? My goodness, I hope no one I know is responsible for the stunning array of marketing failures I have witnessed during these past few days. I mean, I always knew Sun wasn't the greatest marketeer on the planet. But now it seems like they are going out of their way to alienate many who really care.
That's just... amazing.
9:15 - my talk is over, and Girorgio is up talking about promoting Smalltalk for shops that use 4GLs. So - we know what the advantages of Smalltalk are - how do we transmit those to new customers who think that curly braces are where it's at? We need to promote newer examples (BottomFeeder!) What about the "ordinary" requests: The standard DB oriented CRUD apps that people need "immediately". Here's Giorgio:
So you've sold these guys on the power of Smalltalk, but can you show them that the "simple" stuff is actually simple? Heh - it often seems that we (Smalltalkers) prefer to get complex requests so that we can show off our meta models, etc. When they see us defining classes in a browser, defining instance variables, defining setters/getters.... it starts looking complicated. Then we go into the GUI Builder - bearing mind that the 4GL shops are used to having things generated up from the DB schema (this may not be a good answer, but it sure looks good).
So, the standard IT shop can do the simple stuff gets done very quickly with these tools. That gets translated up for other things (and Smalltalk is hardly the only thing that runs into this). They probably got a Java demo, and thought that looked too hard too. The point is - if you can't do the really simple things quickly, then you don't even get to enter the race (these are places that are currently ruled by FoxPro, VB, et.al.). Yes, those "simple" apps get complex and the 4GLs fall down. It doesn't matter - they started there because they weren't convinced by what you showed them.
So - Giorgio has built a lot of tools (more involved versions of the slam demos I did when I was an SE) that allow you do the simple things quickly - simple data mappers that generate code and UI elements. What Giorgio is showing looks a lot like what I did back then, actually (mine were not much past demo-ware - Giorgio is using his stuff in real applications). He's got the goods - generate a form, have it handle the CRUD functions.
The good thing - underneath the generated forms and code are domain objects living on top of an object/db mapper. That means that a developer can take the results forward without being trapped in the "it's all GUI" problem. So it all goes like this:
- create an application definition file called default.ini, which defines the mapping
- Execute this: BasicApplicationSystem initializeSystem
- Run the application like this: PhoneContactView new openMaster
- Total time spent: 1 minute
That allows Smalltalk to enter the race against 4GLs, by making the simple stuff simple. We can then demonstrate where Smalltalk adds value that the 4GL can't - but we had to get to that point first. Giorgio's system also handles non-trivial examples that have more complex object/relational links. As well, you define your domain objects and generate a database schema from that.
He's made it all pluggable, allowing pre/post actions for objects on db actions (CRUD). All looks pretty good - it's a professional version of the hack work I did for demo purposes as an SE. The difference being (again) - that Giorgio's stuff is in actual production use and works there. Now there's a demo - it's pretty cool stuff - and the db mapping code works across VW, VA, VSE, and Dolphin. He's also got a C# version. He's interested in Pollock first, and possibly GLORP after that.
Rogers Cadenhead does some digging, and finds out that the Grokster (correction from my first post, where I somehow said Kelo. Clearly, not enough sleep this week. Thanks to the comenter who noticed) case will enable BitTorrent to be smacked down - here's what the author said about it back in 2001 on his website:
I further my goals with technology. I build systems to disseminate information, commit digital piracy, synthesize drugs, maintain untrusted contacts, purchase anonymously, and secure machines and homes. I release my code and writings freely, and publish all of my ideas early to make them unpatentable.
Goodnight Irene. Time to find a new tool, and to explain that Loose Lips sink technology tools under the new legal regime - at least in the US.
I came into this talk late, due to a STIC meeting - and found out that Windows had inexplicably shutdown. Grrrrrr. Anyway - here's Michael, talking about SwS:
The roadmap - they are going to Pollock for their version four engine, which is faster than version 3 (current, what I use in Bf). It's also richer, and will support CSS3, better boxing, and complete widget embedding capabilities. They are building a nice set of domain mappings - Smalltalk widgets to the DOM tree, the DOM tree back to Smalltalk, and CSS widgetry to Smalltalk objects. That means that changes to the XML and CSS will be immediately reflected in the UI.
Demos - the example browser. He likens it to Gecko, in that it's the basis that you might use to build a full browsing tool, not a full tool in and of itself. It does a good job though - it renders CSS Zen Garden quite well. Going to their website, it's nice to see BottomFeeder getting a plug - and he points out their developer program - I'm in that, and they are quite responsive.
Now he's showing the engine used to build a slide show - very nice, and he's using that to do this talk. Next - the Pollock version showing the editing and embedding capabilities. Here's the CSS Zen Garden thing:
There's a lot of this demo that's impossible to translate well here - the movement back and forth between display and on the fly changes to the CSS and/or XSLT is pretty cool. The backmapping is seamless, and something that the developer doesn't need to think about.
Another nifty demo - the welcome workspace as a WithStyle window. Pretty neat - styled, executable Smalltalk code in a Workspace.
Their first delivery is something they call EzyXML, which is an XML editor (akin to what's in the posting tool we use in Bf, but made more user friendly). It's in production with the Australian federal government for XML editing. They create XML, which is later transformed to XHTML via XSLT.
Here's Suzanne, talking about community marketing efforts:
Suzanne has explained the Add ons and Applications program (soon to be announced) that will help publicize Smalltalk products that work with Cincom Smalltalk - we'll work with any partner in whatever way makes sense. We have also been working with KSC, and Gemstone, and with Objectivity - and we plan to expand our scope there. If you haven't seen Suzanne yet, you will - she lives at 30,000 feet :)
Comment from Bruce Badger and others - get the ANSI Smalltalk effort back on track to standardize various things that need it (sockets, etc). What about the kind of "fluff" advertising that MS and Sun do? Well, we don't have their budgets (on the other hand, unlike Sun, we have profits :) ).
Here's the coding contest - each player goes against another, with 1 minute in a game to hack bugs away. Here's Kevin hacking:
Now Blaine sits down - let's see if his client stays up. Nope - he's hacking:
Nope - Blaine goes down, Kevin wins by default. So now we have Michael against Kevin - the game is afoot. Looks like Kevin is hacking a hard coding of "localhost". Kevin fixes the bug, and we have a game going - looks like a stall, not a walkback for Kevin. He's hacking at it:
And he got that addressed, the game goes on. Michael wins, and Blaine is back up against Michael. Probably back to the debugger. Yep, Blaine is trying to fix his bug, but no move - Michael wins round two. So, we have Kevin vs. Blaine - will we get a move - nope, Blaine heads back to the debugger:
Blaine loses by default, so we have Michael playing Kevin again. This should just run, now that all the bugs are fixed - the moves are happening. Michael loses to Kevin, so there's a tie for the lead. Now we have Michael vs. Blaine again - will Blaine head back to the debugger? Yep - he's up there again. Looks like Blaine's client might not be waiting for Michael to move, which is causing illegal moves unless Alan intervenes at the server. No fix - Blaine is down and out.
So we are now trying to see if the two clients - Kevin's and Michael's - are deterministic based on who goes first. We now try each in position 1 and 2 again. Seems to be deterministic - the first game ran exactly like the first time - the second one as well.
Here's a (not great) shot of the game screen:
So, the tiebreaker - we run Alan's simple minded "play the smallest coin possible" client playing against each. Alan vs. Kevin: Kevin beats Alan's client twice. Reset, we try Michael vs. Alan: Michael's client lost by one - now we try again, just for completeness: Michael wins as player 2. However, Kevin won the tiebreaker both times, which ranks it out:
- Kevin Badinger - Check for $1000
- Michael Lucas-Smith - iPod
- Blaine Buxton - iPod Shuffle
So - congratulations to the finalists, and to all the entrants - see you all at next year's contest!
Niall Ross on the value of Smalltalk:
"The things you lean from experience are better than what you learn from theory" - they sink in better. Learned Smalltalk on the job, liked it straight off. Later on, at Nortel, found that management was very keen on Java, but Niall found that he couldn't get enthusiastic about it. He's been pondering the why of that since then.
So - why does Smalltalk give value? Consider Statically typed (Niall calls them "stiffly typed") languages: they represent the ultimate attempt at up front optimization. This violates the basic tenet: First make it run, then make it right, then make it fast. Looked at another way, you'll almost certainly get it wrong the first time.
- C#, Java - designed by and for those who expect to be right the first time
- Smalltalk - designed for those who don't
The first example - the Kapital project at JP Morgan. The goal - the ease of a spreadsheet with the scalability of a system. I'm not taking full notes on this example - Niall went into detail on this at last year's ESUG conference.
The basic message Niall gleaned from working on the Kapital system: Meta-modeling is so easy in Smalltalk - that you can actually deliver. Why is meta-modeling so easy? Smalltalk exposes the meta-model - everything is an object, there are very few reserved words. In other words - the language lawyers don't get you down :)
Ralph Johnson's framework rules:
- build one when you need to
- when you've done something three times
Smalltalk is good for this because everything is an object - nothing resists becoming a framework object. Every type is an object; mix and match generic algorithms with specific overrides. Smalltalk frameworks can be built in an agile way, deferring decisions. C# and Java aren't so suitable - meta data patterns are brittle even in simple cases.
Heh - a question about Lisp and meta-modeling. Niall said that he could easily imagine himself as having come to Lisp instead, or favoring Smalltalk even knowing Lisp better - but such a statement would be respectful, as opposed to the his feelings towards Java.
Lots of good conversation afterwards, which I just didn't capture.
Jeff Hallman, who works at the Fed in DC - his application tracks the money supply and is responsible for the reports on that - the ones that come out every week. Here's Jeff:
So - definitions:
Reserves are the deposits at a Federal Reserve Bank. The supply is based on Fed actions Demand is created by reserves requirements on transactions deposits. So what do they publish?
- H.6 - Money market measure (M1, M2, M3)
- H.3 - Aggregate reserves of depository institutions and the monetary base - this used to be tracked heavily by the markets (in the 80's)
- Available at http://www.federalreserve.gov
MARS (Money and Reserves System) is their application. Loads serveral dozen reports and adjusts for reporting errors. Recalculates (C functions), and does forecasts. This is basically a huge matrix with thousands of columns. It creates summary reports, stores data back into the money files, and does session management over the whole thing (for analysts).
The components that get used?
- R (Graphing package)
How did this end up in Smalltalk? It used to be PowerModel and C, where PowerModel had become legacy (company had gone under). Jeff convinced his management to go to Smalltalk after a bit over a year of lobbying (I made a few visits myself). It's running on Red Hat at the Fed, he's demonstrating it on his laptop.
Like a lot of critical Smalltalk applications, this one is delivered to the analysts with the full development environment (hidden) - something that one of my frequent commenters seems stunned by, since he constantly blathers on about the power of dead tools where you can't do that sort of thing. Fine - we're busy being productive over here :). Changes in the old system took weeks - he typically makes requested changes in an hour or two - because of what I said above.
So anyway - the analysts can look at the data in a grid, or in charts (seasonally adjusted or otherwise). I've got a chart screen shot here with some large swings (this is monthly data) - Jeff points out that the swings are due to something called "Sweep" accounts, where banks push money around as a reaction to the vagaries of current law:
The reports that this application produces get used by the fed board members to look at trends and help make policy - so it doesn't get much more mission critical than that :).
Interesting note - the earlier system took about 3 years to write, by 2-3 people - about 83k lines of code (C, PowerModel). The Smalltalk system is 21k lines of code. In terms of actual characters, the comparison is 3.2 MB characters, as opposed to 605k characters in Smalltalk. It took Jeff (one guy) six months of work. So... the productivity comparison is 5-6x better in Smalltalk, with fewer people working on it.
Last talk of the day, and of the conference - Bruce Badger is going to tell us how Smalltalkers can benefit from what he's doing with the OpenSkills organization - and how they use Smalltalk at OpenSkills. Here's Bruce:
What is OpenSkills? An open forum for networking and work support services. They provide a free, searchable skills base. They are a non-profit, so as an organization they have no money. So - all development is a volunteer effort, and Bruce, knowing Smalltalk and Java, would rather use Smalltalk (takes far less time. Observation: For consulting firms, Java is a great choice - takes 3x as long, so that's 3x the consulting dollars :)
- They have an evolving data model
- They need to be scalable
- They need distributed development
- It makes good use of a scarce commodity - volunteer developer time
All of their web apps go through Squid as a reverse proxy, which gives them simple, secure connections. Their back end database is Gemstone. They've written the SkillsBase application so that it runs either in VisualWorks or in Gemstone - they actually run Swazoo out of Gemstone.
The membership system is a combination of:
- A complex and underdefined process
- lots of external interfaces
- little time
- Those are ideal for Smalltalk use, as it allows for easy evolution of the system as time and details allow
They are getting a lot of help from the open source community, both in Smalltalk and in Ruby. What do they see happening? They are seeing a lot of interest in Swazoo, Glorp, and Seaside. They are seeing a lot of interest in Squeak and Gnu Smalltalk. This is leading to an increased use of Smalltalk in the open source community.
What would Bruce like to see?
- More ANSI work (streams, files, FFI)
- More standardized ANSI interfaces for common libs (sockets, Dates/Times, etc)
- Deployment simplicity- a beginner should be able to deploy "Hello World" (as a deployed app, rather than as a dev env). Yes, that's top of my list
It's been a really, really great three days - lots of catching up with friends and customers, lots of great conversation at the bar each evening. Watching the coding contest this afternoon was a blast - the guys had a lot of fun, and I expect we'll see more of that next year. Which reminds me - we decided on Montreal as the venue for next year, but we don't have dates or the hotel nailed down yet (we are pretty sure about the hotel, but I don't want to gte ahead of myself). To those of you who weren't here - come next year, you missed a great time! For everyone who was here - hope to see you again real soon!
ZD Net: "Asked about the future of its .NET strategy, Ballmer admitted the platform 'had stalled in the last 12 months'. But there would be a renewed .NET push, he said, and this was 'an assigned priority' for the government sector. " - I recently spoke to a former Oracle employee who said Microsoft was going to drop .NET as a platform. Of course I didn't believe him, but comments like "has stalled in the last 12 months" make me wonder why? Microsoft is betting the farm on .NET, right?
Oddly enough, we were talking about .NET this evening after StS 2005 wrapped up. My opinion - they went a "bridge too far" pushing VB to .NET - it's just too much for the (very large) VB community.
Well, I'm on my way back from Smalltalk Solutions. The flight from Orlando left without a hitch - met my parents, got my daughter, had a pleasant flight up next to a lady who works in the pharmaceutical industry. Interesting niche, actually - her company manufactures drugs for some of the big vendors. Sounds like the way it works is that the big guys do the R&D, and then push the actual manufacturing out to firms like hers. Sounds reasonable, I just didn't know that.
Anyway - I now get to spend some quality time in the Charlotte (NC) airport, waiting for my next flight - which is 40 minutes late, pushing the departure time closer to prime T-storm time. We'll see how that goes. In the meantime, no Wifi - there's a weak secured signal, and then the normal number of open computers hanging around - no public system. Sigh.
So it's hurry up and wait - we are supposed to meet friends for dinner this evening, but it looks like my wife might be doing that without us.
"In his maiden speech to the House of Commons, the Hon. Member for Copeland, Jamie Reed MP, announced that he is a Jedi: "as the first Jedi Member of this place, I look forward to the protection under the law that will be provided to me by the Bill" (the quotation is a fair way down the page; search for 'Jedi,' not surprisingly). How long before we have a Congressional equivalent?"
Someone call for the cluestick...
Lambda the Ultimate points to an interesting commentary on generics (as done in Java, but I think the C# implementation qualifies as well) - Generics Considered Harmful:
Any feature added to any system has to pass a basic test: If it adds complexity, is the benefit worth the cost? The more obscure or minor the benefit, the less complexity its worth. Sometimes this is referred to with the name “complexity budget”. A design should have a complexity budget to keep its overall complexity under control.
Humans can't track this stuff. They are always losing which exception to what other exception applies (or doesn't) in any given case.
I've brought this up before. In languages like Smalltalk, we simply don't have this problem -we have unlimited polymorphism, which allows us to make partial or full interfaces without having to follow a baroque set of rules. The Java and C# implementations force the baroque set of rules though, and end up with a cost that outweighs the benefit.
How did they end up there? Ultimately, it's because Gosling, Hejlberg, and the people working with them don't have any respect for you as a developer. The languages they designed were built to "protect" you from the power that you have in Smalltalk (and Lisp, and Scheme, etc). Instead, they decided to wrap developers in a cocoon of familiar syntax and a blizzard of keywords.
Need a feature? We can't trust developers to do that themselves - by gosh, they might blow their foot off or something! Instead, we'll limit the power (and potential productivity) for them. Go back to your school days and you'll recognize this theory of operation - it's called "punishing the class" for the sins of the few.
I actually had this conversation with Joshua Bloch last year at ot2004. After his talk, I got up and asked him about "final" - IMHO, it's simply an awful idea, because it presumes that the initial developer of an API has perfect knowledge about all the eventual uses. That's simply not the case, and I told him so. How did he answer? Well, he said that he (and the Java team at Sun) saw the community of developers as a pyramid. The Smalltalkers are up at the peak, and are smart enough to handle all the power they have. He told me (no, I didn't imply this - it was him) - that the Java community was primarily the lower two tiers (imagine 5 in this pyramid) of developers, and simply couldn't handle that kind of power - so Sun had to shield them from it.
Remember now, this is coming from the guy who was part of Sun's API team, and he was speaking to me as a member of that team. To paraphrase from a 1970's era NY Daily News headline about federal reactions to NYC deficits:
Sun to Developers: You're too stupid to deal with a powerful language
So now that theory of operation is starting to yield negative consequences. As it happens, people need things like generics (or the power to create them in an ad-hoc fashion, as we do in Smalltalk) - so Sun (and MS) have to layer that on top of a design that wasn't really meant for something like that. Keeping in mind their "protect the developer from himself" theory of operation, they came up with the barrel full of complexity that is generics in these languages.
The article in Lambda contains a few amusing examples of the problem, such as this one:
The article contains a few simple supporting examples, include the interesting definition of Java 5's Enum type as:
Enum<T extends Enum<T>>
...which "we're assured by the type theorists ... we should simply not think about too much, for which we are grateful."
One can just about picture the Great and Powerful Oz behind the curtain, pulling the levers and twisting the knobs, all the while hoping that no one stops to consider the absurdity of it all. It's all smoke and mirrors - but really complicated smoke and mirrors, designed to prevent anything useful from ever getting done.
Oh this is just too rich. Two of the architecture astronauts behind Atom have decided that WSDL is too complicated. I don't disagree with them; I just find it amusing based on their work elsewhere.
June 15, 2005 — Two of Sun’s sharpest engineers think that one of the bedrock specifications for Web services is too difficult to use, so they’ve proposed alternatives. “If you print out the WSDL 2.0 specification, it comes to 140 pages or something like that,” said Tim Bray, director of Web technologies at Sun and co-inventor of XML. “It’s not light reading. You’re not in Stephen King territory. It’s densely loaded with abstractions.”
XML standards architect Norman Walsh said he encountered difficulty when he tried to build a Web service and wanted to describe it. “It was not clear to me at all where to start because it’s all very abstract. It’s designed to be flexible in every conceivable way,” he said.
I had a few people as me about what my plans are for BottomFeeder in the next release, so I sat down and made a little list - here's the top things I'm planning to get done before I release 4.0:
- Tabbed browsing. I'd like to have the "browse in BottomFeeder" menu option be able to go to a tab, and I'd like to have ite browsing be able to stick that way as well
- Better detection of online status, and of the nasty "redirect all my feeds" thing that can hit you in a temporal connection (like a 24 hour hotel buy)
- Reorganize the various search options into a single wizard screen
- Create a "define your own feed builder" wizard that can support new feed services
None of those will be particularly hard, but they should make the tool nicer
I dont think Eclipse is a revolution - it only assembles good ideas mixed with good marketing. Nothing really new. It also helps Java developers finding more acceptance for their applications by providing a native look.
Any Smalltalk IDE is much more flexible as a system since it is based on pure objects not on files, static typing and static languages. Some questions you should ask yourself:
Can I fix a bug in Eclipse itself while it is running without restarting or debugging from another eclipse session? Can I add a feature to the debugger even when there is no extension point defined - just since I have to fix it or want to include a tool I need for faster development? Can I save the complete object environment (Object memory) in an image while debugging and continue debugging at exactly the same point the next day or on a different computer? Can I add a new control structure to the underlying language while the IDE is running and without changing the parser/scanner/compiler?
The funny thing is, Eclipse is edging towards an image model while clinging to the dead hand of XML configuration files and static languages. That debugging question, btw - that does come in handy. Our support people have had customers save an image when it gets to a bad state and send it to us - at which point they can look at the actual state of the system. That's a very cool feature, and it's really, really useful.