Fog Creek Software
Discussion Board




Joel, "how does it feel"

To have VB6 cancelled out from under you?  You going to migrate the GUI of CityDesk to DotNet?  Or just keep using VB6 as long as you can?

THIS is the downside to trusting MS for your future.

I know I advised my clients to spend quarter mil in VB6 development that I certainly would have written in Java if I had known MS was going to terminate my software platform.

Matthew Cromer
Wednesday, November 14, 2001

You move on, you port the code, you do whatever makes sense for you.

It doesn't mean you can't be successful.  CityDesk - a Windows app - would have looked like crap and run like crap had it been written in Java.

B
Wednesday, November 14, 2001

Well, now Joel can make money on the upgrades.  But seriously, I think WinXP will keep enough backwards compataibility to allow CityDesk to run for a long while.

Java on the desktop is far better than people think, but someone really serious should wait for JDK1.4 to be released and see how performance is.

The caveat with Java is not speed but memory.  The libraries are reasonably fast, but memory is traded to get that speed.

forgotten gentleman
Wednesday, November 14, 2001

Matthew, I don't think your analysis of VB6/VB.Net is entirely correct. Even though VB.Net does not compile VB6 code, VB6 still compiles VB6 code and I expect it will for a long time. There's no requirement to port to VB.Net.

So I haven't had anything pulled out from under me. There's no time expiration on my VB6 compiler and Microsoft isn't going to refuse to let me use it. They might stop "supporting" it, but who cares -- I chose the platform because I know it works as is, not because of any mythical "support" from Microsoft.

The only way I might get in trouble is if a new OS comes out with some must-have feature which is only available from .NET. So far, the OS guys at Microsoft have always been hardcore about always having full Assembler/C APIs for all their functionality. So until they release an operating system that simply won't run VB code, I'm pretty safe -- and Microsoft has a reputation for backwards compatibility that is second to none. Heck, I could be using a 16 bit compiler, thanks to thunking and COM, and still do just about anything I wanted on Windows XP :)

If I develeped Mac software I would be used to the fact that you have to port your code for every major release of the operating system. But in Windows this has never been the case.

My estimate now is that we could probably get our existing code compiling under VB.Net with about 2 weeks' work. This might be worth it to get the benefits of a better development environment. Right now we're going to wait at least until .Net is shipping, and then we'll wait a while to see how many show-stopper problems there are with .NET 1.0 before porting. Chances are there are a bunch of things that we need to be able to do which don't quite work yet in .NET, and we're going to wait for those to shake out.

When you say "MS was going to terminate my software platform," this sounds like the kind of comment you hear in a room full of CTOs and MIS managers who read InfoWorld and News.com and don't entirely understand what they're reading. You make it sound like Microsoft decided I couldn't use my compiler any more. I too am annoyed at the lack of compatibility between VB6 and VB.Net, I think it was a dumb move, but it's not going to hurt my product or my business.

Joel Spolsky
Wednesday, November 14, 2001

Glad to hear you will be able to port.  I was feeling worried for you.

I can't possibly do a code port.  My framework is based on COM and very componentized into COM / ActiveX components and controls.  Truth be told, if I knew what a mess COM was when I started the framework I would have figured out another approach.

I suspect we won't be able to run the framework code in a few years.  VBs flavor of COM hardly works for us now (admittedly we push it to the absolute limit) and we have to manage the VB environment heavily and compile in "special" ways to make our usercontrols load dynamically, etc.  Given the level of bugs we have to deal with, the registry crap we have to clean up, and the unresolved issues with Windows 2000 we have to deal with it doesn't take any imagination to see the whole edifice collapsing of its own heavy COM reliance in a few OS releases or even service packs.  We drank deeply of the COM kool-aid and now we pay the price.

We have been doing a lot of java work lately and can compile all of our java stuff (up to and including the JDBC drivers, XML drivers, etc.) into a single JAR file, eliminating the dependencies problem that eats our lunch on the MS platform.  I can't describe the absolute pleasure we get out of deploying an application with its own libraries unchangably bound with the executable.  At least after being burned again and again by DLL hell.  Back to the future I guess.

Again, I am glad to hear you will be able to migrate to VB.NET without a complete rewrite and rearchitecture.

Matthew Cromer
Wednesday, November 14, 2001

An another responder wrote:

"CityDesk - a Windows app - would have looked like crap and run like crap had it been written in Java. "

I'm trying to understand this message.  I've seen a lot of desktop applications written in java that neither look like crap nor run like crap.

The java IDEs I use (written in Java) go down maybe once a month.  My VB6 IDE GPFs every 30 minutes or so.

I've seen a number of java applications that are fast and very reasonable in memory usage.  Heck I've seen emulators written in java that emulate 68020 processors and play video games under emulation (there is no more demanding application than a virtual machine emulation of another hardware platform).

Matthew Cromer
Wednesday, November 14, 2001

You can call COM components from .NET assemblies, and vice versa. There's a performance penalty for the translation layer, but it works (admittedly I am not pushing COM to its limits, whatever that means). In the general case, migrating from COM to .NET does not require a complete rewrite; you can do it one component at a time if you like.

Mike Gunderloy
Wednesday, November 14, 2001

The bottom line is that the framework has to be rewritten.  And I'll be rewriting it in Java and expect to use it for the next 10+ years.  There was no particular need to rewrite it from scratch, but I can't market a COM based solution in this brave new world.  Thanks a lot, Microsoft!

Matthew Cromer
Wednesday, November 14, 2001

I agree with you Matthew

When COM first came , it was heralded as some Nirvana.

Some one told me Billy boy has decided that in .NET, COM is not going to be there any more, although supported for backward compatibility.

Well, COM was OLE with a new name. If i am given a chance between full blooded OOPS using C++ or Oracle Java and Visual Basic with COM , OOPS  will score over COM anyday.

Reusable classes are "more reusable" than reusable COM components. Can you imagine having 500 COM objects in the registry ?. Ugggh...

One ERP application we developed using OOPS had more than 1500 reusable classes. We probably had 5-10 COM Components. It was a mess to port the COM components from OLE to COM.

Karthik.S
Thursday, November 15, 2001

Along these lines, check out the open source IDE / platform (that cost IBM $40 million) from eclipse.org.  It's one of the nicest looking and running pieces of software that I have ever seen and its Java.  They even have come up with a widget set that looks "right" on each OS it runs on.

If Fogcreek is ever going to go cross-platform, just about all of the services that they would need are provided on this platform, although the I have no idea about the relational data store.  I would bet that it would be a *much* easier port than to GTK Linux or Mac Cocoa.

--Tim

Tim Randolph
Thursday, November 15, 2001

Eclipse works well because it doesn't use Swing. The developers created their own libraries that map native widgets to Java objects... IMHO, that's what Swing should have been.

So, you can only use Eclipse where they have made bindings to the native window system (Windows and Linux)... and you won't be able to integrate Swing components that others have written.

I'd love to see Eclipse's libraries catch on and supersede Swing, but that would take a while.

(BTW, I like the idea of using wxWindows for cross-platform-but-using-native-widgets development. You can write most app code in Python and then dive into C for things that need to be fast...)

Kevin

Kevin Dangoor
Wednesday, November 21, 2001

The problem with Eclipse-style GUI widgets is that you can't really create new widgets except for the really trivial cases where you're just reusing the native ones.  I haven't looked closely at Eclipse, so I may be off here.

I do think though, there's a place for both, and Eclipse's GUI system will certainly buy time for Swing to come into its own while under attack by Microsoft's .NET.  This fragmentation in the Java community is important and good.

forgotten gentleman
Wednesday, November 21, 2001

Forgotten gentleman is dead-on.  Anyone who thinks JAva performance, or even Java GUI performance is poor, probably hasn't used it in several years.  I would add that it doesn't look bad at all.  In fact it seems to follow Joel's rules for GUI design a lot better than the standard Windows GUI widgets.

The memory is an issue, though even that has improved, and for many types of projects, the benefits you get for this price are well worth it.

Erik Lickerman
Sunday, November 25, 2001

Thoughts on some major Java applications I've used:

1. Borland's JBuilder:  This is the best Java-based application I've used.  Yes, it's a huge memory hog, but I have plenty.  Sometimes when I've been running it for a long time, it will take a break--I suspect the garbage collector.  An annoying problem, but rare enough that it isn't a big problem.

2. webMethods:  The Integrator product is written in Java and works very well, IMO.

3. Tibco:  Much more clunky looking and feeling, but functional enough.

Scott Carpenter
Saturday, December 01, 2001

I last used Java about three weeks ago - I tried using NetBeans as an IDE on some Dell box (not sure what it had under the hood).

I timed the application startup at one minute and 30 seconds from double click to usable window. That is simply unacceptable.

And even after the app was running, it still dragged. Menus were noticably slow in coming up. Switching between edit/debug etc. took a visible amount of time shuffling windows. etc.

I don't know if this is Netbeans itself or Java in general, but the performance in that experience just sucked.

Chris Tavares
Sunday, December 02, 2001

*  Recent Topics

*  Fog Creek Home