Follow this link to Mark Watson's web log. It's got some wonderful comments on the stability and compactness of VW based services vs. Java based services: An excerpt: I then started doing some work on my virtual private server (I use a service that runs many instances of FreeBSD per physical server - for a small monthly cost, you get a machine on the internet that you have root control over. The only problem with this otherwise wonderful service is that they do limit the amount of virtual memory that your FreeBsd instance gets. OK, now you see where I am going with this! Running Java under severe memory limitations... Anyway, in the past, I have had really bad luck running Jakarta Tomcat on my virtual server because of out of memory errors. Tomcat is usually my favorite Java development and runtime platform. Love it. Can't run it on my virtual server. SOOoooo, I installed Jetty - much better, now I can run JSPs and servlets on my virtual server. But, the memory footprint is still huge. As a comparison, I keep a demo web services application instance running all the time on my virtual server that is written with VisualWorks Smalltalk (version 7). This application has embedded servlet support and something very close to JSPs. I also have SOAP services built into the application (still working on this, but it will be both a SOAP server and use remote SOAP services). For you Java developers, I just don't want to tell you how small this memory footprint is. Really, it would make you feel bad. For non-Java users, email me, and I will let you know :-) Go read the whole thing.
We have been looking at memory leakage in BottomFeeder - more specifically, in the embedded Twoflower browser. This morning I went a release too far though - I cleaned up enough dependencies that the HTML View simply stopped working.... A new DEV build is up that addresses that - if you have a DEV build that does not work, grab the latest. Maybe next time I'll actually test before I upload....
We should be upgrading the download site shortly - and this will make the whole process run far more smoothly. Stay tuned - we will be unifying download registration and Store account registration, which should make it a lot easier to use.
One thing we failed to do is place the updated version of Net Clients that we are using on the site. The requisite code is in the public repository, but it would be simpler just to provide the parcels. We now have those here. If you would like to load the sources, you'll need to replace your visual/net directory contents with what's in the file above - and, you will need to load the URISupport parcel over the one that is in the base image.
I finally attacked something last night that I had been avoiding for a few months - the way we do slim mode in BottomFeeder. The code in all released versions uses the same ApplicationModel, and does a map/unmap trick with different interfaces. This led to a set of ugly code that switches the two views, and ensures that all windows actually close when you quit (in fact, the deployed version explicitly issues a system quit to make sure we don't have a problem). So last night I decided to look at making it two different classes, and simply switching between them via open and closeRequest. Lots of code died. And the separation between application layers became more obvious. And the complexity disappeared. It was an all aoround good idea to go in and have a look, and it should make all UI related work simpler going forward. It's likely you have some overly complex code somewhere - go ahead and simplify it - you'll be happy you did.
Joel on Software as a fascinating post today. He's talking about a book, Critical Chain. Here's an excerpt I can certainly identify with:
We had a memory leak we were apparently too blind to see. In our application, we have a singleton object that handles feed access - and it turns out that said object ends up with indirect holds on UI objects. By clearing that, we get rid of a leak. So people using the application in a VW development environment should no longer see an ugly buildup of UI instances...
Lex Spoon wrote an excellent piece in cls on the static/dynamic conflict: I just had the culture shock of defending a Smalltalk-based research proposal to a group of professors who love static types. It was wierd that they really don't grok the way a "language" like Smalltalk works. That's not my point, however. After some reflection and some discussion with my advisor, an interesting way to cross the gap came up: focus on the special *environment* that Smalltalk has. The fact is, pretty much all static type systems around only work in systems where you every code change is followed by a re-compile and a re-start. In this kind of scenario, a type checker can start from scratch and just say "yay" or "nay". If it says "nay", the presumption is that the programmer edits the program and resubmits it. It is considered acceptible in such an environment to adamantly require entire programs to be type safe before they are executed or otherwise processed, and it's considered acceptible to have to recreate all of your in-memory data whenever there is a code change. In an environment like Smalltalk, the bulk input and the frequent data recration both go away. Instead, programmers make one or two changes and then run their code some more to see how it is faring. They'll even reuse existing instances to try their changes with. TO DATE, THERE IS NO STATIC TYPING SYSTEM WHICH FUNCTIONS IN SUCH AN ENVIRONMENT. The hardest issue for such a type system would be to deal with existing data: if you have live objects floating around, then changes to their classes will make those instances become non-type-safe. This problem is pretty much the same as "database scheme evulation", a difficult problem that has received a lot of attention in research. A second difficult issue is that it may require multiple changes to reach a new type-safe program for a simplistic type system. Somehow the system *must* deal with the intermediate stages between type-safe programs, in order to maintain the nice environment. Again, this is clearly a very difficult problem. (Well, clearly if you've used Smalltalk.) By focussing on the environment style, the points are very clearcut and thus the discussion is much calmer than is usual with this topic. The debate boils down to a choice of environment style: is it acceptible to do batch inputs instead of developing a program with live data floating around? This is not to say that other issues in the dynamic/static typing debate are no longer interesting. For example, it's still true that there aren't any good OO type systems, and it's still true that for most practical purposes static types don't buy you very much. But in addition to being more diplomatic, the focus on environment style really gets at why *I* at least don't want to use static types: with today's typing technology, static typing means giving up some of the best features of Smalltalk. In fact, if there were a type system that would let me work in Smalltalk as usual, then I for one would be okay using it. I even wish there were more researchers focussing on static typing for such environments! My issue is simply that, there is no static type system at all that functions in a Smalltalk-like environment. Now, we just need a spiffy name for this style of environment....
Lex Spoon is back at it, with more excellent points: Lex's original post got this response:
"If a component offers a service/API to the "world", such service/API should be as reliable/explicit (and this is where static/manifest/explicit typing --and again, only with interfaces-- helps) and stable as possible for optimal client/provider relationships. Refactorings should, and are supposed to, improve the implementation without altering those public services/APIs. "To which Lex then responded:
If anyone really thinks static typing makes modules so stable and reliable, they should think about all of the alternative OpenGL libraries for MS Windows. Think about (for anyone who remembers) all the winsock libraries for Windows 3.x. Even think about libc on Unix -- many programs that had been ported to several Unices had to be tweaked again when Linux came around with its slightly different libc. In all of these cases, people drop in modules that have typed, verified interfaces and which have been heavily tested in isolation; but wierd behaviors result anyway. Making reusable modules is already hard, and making *drop-in* reusable modules is much harder still. Static typing doesn't do much for this problem as far as I can see -- you need a ton of verification and validation work with or without the types, and just as with unit testing, the testing will test the types along the way of testing the functionality. If you want types, don't want them for reliability. They are good for documentation, for example.... But then, I'm not convinced that a responsible programming team couldn't manage to write documentation, anyway. Do you ever hear engineers talking about self-documenting bridges?
I have been deep in the bowels of an object identity problem today, and trying to get my presentation for Brazil in December. Busy, busy....
So now I can have it looked at for comments. I plan to talk about XP practices, and why they arose in Smalltalk (as opposed to, say, C++ or Java). In fact, I doubt that XP ever would have arisen in Java, and I don't think it can ever be optimal there...
We had some entertaining problems over the last few days, but I think we have worked through them. We have:
- Added a search capability. You can now search for keywords in the feeds - titles and/or bodies
- We got the feed images to show again. There was an oddball issue with accessing the widget in a subcanvas, which we addressed
Unless I find a wireless connection later. I have to head down to Washington to get a visa for my Brazil trip next month. Starbucks says they have Wireless connectivity - I guess I'll find out.
Wireless connectivity at starbucks with my Mocha. mmmmmmmmmmmm
Ok, I said I wanted comments on my draft presentation for the trade show I'm speaking at - so here's a link to my draft. any and all comments welcome!
If you take a look at the presentation I'm giving in Brazil, you'll notice that I'm going more on the offensive than Smalltalkers normally do. Well, here's my rationale - being accomodating and merely talking about interoperability hasn't helped. Look at Apple's switcher campaign, for instance. They aren't apologizing. They aren't talking just about interop. They are touting all the reasons why they feel Apple is a better solution. This is what I think it's well past time that the Smalltalk world did. Interop is great, and necessary. But it's not a compelling reason to use Smalltalk. Heck, if all I cared about was interop, I'd just use Java. Instead, we need to point out how and why Smalltalk is better. Talk up the productivity, and demonstrate to doubters how Smalltalk is more productive. Start touting - as Apple does - that Smalltalk is a premium brand, while Java is the commodity. There are plenty of developers who are pleased as punch about using a premium brand option - just look at all the Apple notebooks you see now at trade shows. That's where Smalltalk needs to go, and we need to take it there. Don't apologize - explain.