Fog Creek Software
Discussion Board




REALbasic article questions

I've been a Mac user for over a decade, but finally (two days ago) bothered trying REALbasic at home and quickly found out it blows Java out of the water when targetting the Mac.

Read Joel's article on REALbasic (http://www.joelonsoftware.com/articles/fog0000000051.html) and it seems to go like this:

"REALbasic is so close to having Visual Basic's syntax and has none of the "strange GUI behavious" that turn people off when they use Java.  If RB had a "strict VB" setting, I could use my legacy VB code to do 90% of the porting to the Mac.  If I could port my VC++ code just as easily as a REALbasic plugin in CodeWarrior, all I'd have to do is move a few controls around and I'm done!"

Well, I get paid to do Visual Basic and have been for years, so I see where Joel's coming from.  At the same time, his article left me with a few questions:

* Does C++ give that much of an advantge behind the scenes because it doesn't garbage collect? Why not use Java for your xplat heavy lifting code?
* What about COM makes it that much better than opening a pipe between the GUI and the engine?
* How tough would it be now to write an RB to VB.NET converter? I've been wondering about that for a while (what, two days? :^D).

If you ask me, a REALbasic (which compiles for Mac OS X, OS 9, *and* Windows 98-XP) GUI lain over a headless Java (or ANSI C) app seems to be the best way to go to get good xplat applications written.  Sounds like that article (admittedly a little dated) is a little biased towards (surprisingly enough) people with a right sizable COM compliant legacy codebase.  ;^)

Ruffin Bailey
Wednesday, June 12, 2002

This is also mentioned in the current Dr. Dobbs... maybe I should read it.

Joe AA.
Wednesday, June 12, 2002

Java will never replace C++ in the background "heavy lifting" process because Java doesn't play nice with anything but Java. C++ is often used to access pieces of the OS that VB can't. Java won't let you do this without writing JNI code in, guess what - C!

Also, lots of the stuff that gets written in C++ is bit twiddling that needs to be fast - image processing code, for example. Java really doesn't do well in that department.

Chris Tavares
Wednesday, June 12, 2002

Yep!!
Let's face it, Java is little more that C-Shell on
really bad steriods :-)



[Java will never replace C++ in the background "heavy lifting" process because Java doesn't play nice with anything but Java. C++ is often used to access pieces of the OS that VB can't. Java won't let you do this without writing JNI code in, guess what - C!

Also, lots of the stuff that gets written in C++ is bit twiddling that needs to be fast - image processing code, for example. Java really doesn't do well in that department.

]

Netbui
Wednesday, June 12, 2002

Netbui:

Did you come here from Slashdot cause the lameness filter was cutting down on your posting? I take it you don't like Java. Lack of access to the OS in a non portable way may be a problem for some applications but I'm not sure that I'd equate such access with being able to do "heavy lifting". Does heavy lifting mean complex algorithms and difficult computations or bit twidling? If complexity is the issue then an even higher level language would be the answer, perhaps develop some sort of domain specific language. If it's "just" bit twidling write the smallest thing you can in plain c or c++ and call that from the high level language you prefer, or from your DSL. Certainly image manipulation in java wouldn't be my first choice :)

Alex Moffat
Wednesday, June 12, 2002

Actually Alex M.,
Java is lame for just about anything really useful.
Please name 1 usable generally avialable Java Application/Product, the people would actually dare use unless they have a lot of MIPS.

I mean real application performance of Java simply sucks!
Call it what it is... it blows wind period!!

Cute web applets don't count either!!



[Netbui:

Did you come here from Slashdot cause the lameness filter was cutting down on your posting? I take it you don't like Java. Lack of access to the OS in a non portable way may be a problem for some applications but I'm not sure that I'd equate such access with being able to do "heavy lifting". Does heavy lifting mean complex algorithms and difficult computations or bit twidling? If complexity is the issue then an even higher level language would be the answer, perhaps develop some sort of domain specific language. If it's "just" bit twidling write the smallest thing you can in plain c or c++ and call that from the high level language you prefer, or from your DSL. Certainly image manipulation in java wouldn't be my first choice :)

Alex Moffat
Wednesday, June 12, 2002

]

XP Man
Wednesday, June 12, 2002

---------------------------------------------------------------------
...cause the lameness filter was cutting down on your posting?
-----------------------------------------------------------------Alex

Nice insult.

Ged Byrne
Thursday, June 13, 2002

I don't think Joel was criticising Real Basic as a technical product, but as a missed commercial opportunity.

A little extra work could have made REALBasic VB compatable, which would have opened up a much, much  bigger market.

Ged Byrne
Thursday, June 13, 2002

"Please name 1 usable generally avialable Java Application"

jedit.

go stand in the corner.

nope
Thursday, June 13, 2002

Tomcat and JSP in general. 

Ged Byrne
Thursday, June 13, 2002

Im earning good money with Java and JSP. My clients find the software usefull. The performance problem goes away with a jit compiler. It does need alot of mem though...

Eric DeBois
Thursday, June 13, 2002

Eric - which runtime are you using? the ui behaviour of the older ones are a bit slow, but with 1.4 is almost as good as native code. i'm actually intrigued whether this is because the whole vm is faster, or if the thing is threaded and they have raised the priority of the ui thread (call me suspicious if you want :-) of course, i'm not interested enough to want to do any benchmarking myself, but i'd like to know if anyone else has.

nope
Thursday, June 13, 2002

[I don't think Joel was criticising Real Basic as a technical product, but as a missed commercial opportunity.

A little extra work could have made REALBasic VB compatable, which would have opened up a much, much bigger market. ]

My question was if Joel wasn't seeing the glass half empty instead of half full.  If I wanted to shoot for 99.44% of the desktop market, I might switch from VB & VC++ to a different set of technologies.  To say RB needs to have a "strict VB compliance mode" and that RB plugins should allow for VC++ to compile in Codewarrior sans a change is great if you have legacy code on Windows, but from a purely theorhetical perspective there might be a better way to skin the cat.

Java is fast.  Java GUIs are not.  IBM saw this and created their own toolset for Java GUIs, SWT (used in Eclipse, http://www.eclipse.org ).  But for headless apps, like Tomcat in specific and JSP as a general example, run just great with Just-In-Time compiling and the like.  And if you're worried about keeping porting costs to an absolute minimum, there's no better way than using headless 100% pure Java.

REALbasic allows for opening pipes to command-line apps (with OS X & Windows, at least (ie, not Mac OS 9-)).  Now you've got a crossplatform (at least Windows and Mac) GUI RAD with the RB IDE, and pipes to replace COM -- not to mention an xplat app out of the gate (minus some time to rearrange controls for the target platform to meet user expectations).

So my question is if Joel saw the glass half empty for any reason other than that he already had many "man-years" of legacy code in COM-compliant technologies.  If he didn't, REALbasic might have been his answer.

Thanks for the reply.

Ruffin Bailey
Thursday, June 13, 2002

COM ain't just for windows, folks.  Pick up a copy of 'Inside COM' or take a look at XPCOM:  http://www.mozilla.org/projects/xpcom/ 

those who know me have no need of my name
Thursday, June 13, 2002

"A little extra work could have made REALBasic VB compatable, which would have opened up a much, much bigger market. "

Oh yeah... sorta like Borland's introduction of the "quirks mode" compile switch in TASM to emulate the bugs in MASM.

Joe AA.
Thursday, June 13, 2002

COM *can be* better than pipes because when the client and server are running in the same thread (as is often the case for single process engine + GUI) invocations become simple method calls. The COM/DCOM marshalling layer also nicely hides the difference between in-proc and out-proc invocations. OTOH I would probably prefer sockets whenever the GUI and engine are on separate machines.

C++ is generally assumed to be an order of magnitude faster than Java. Whether or not this is a factor depends on the type of code you write. It is generally correct that choosing the best algorithm is the most important thing and that a higher-level language makes that easier. Unfortunately IMO Java is not sufficiently higher level than C++ to justify the penalty. Personally, I use Java only if I need a multi-platform executable.

Finally there are numerous environments/utlities for fast/painless generation of GUI. Delphi, VB and even DHTML (with script) come to mind. If the advantge of RB is just Mac compatibility, well, for most that's not enough.

Dan Shappir
Thursday, June 13, 2002

> Does C++ give that much of an advantge behind the scenes because it doesn't garbage collect? Why not use Java for your xplat heavy lifting code?

I've just written a run-time application profiler, using C++. I hook every function which the application imports from the O/S or from any other DLL. Each time the application calls a hooked function, I measure the duration etc. of that function call. My hooks add approx 2 microseconds to each function call. I keep this time low by having all my memory preallocated, by controlling my data-access (insert/update/delete) so that it's thread-safe but optimally fast, I drop to assembler (to preserve the machine register values) in the hook portion. I wrote and build it without using the C run-time library, so that I'm able to hook and profile an application's calling the C run-time library.

The above is only my latest example.

Maybe Java is OK for "xplat" (GUI device output), but for really time-critical code, or for "system-level" programming it's just a non-starter.

Christopher Wells
Thursday, June 13, 2002

Of course... we all know assembler is the basis for everything.

Joe AA.
Thursday, June 13, 2002

"Please name 1 usable generally avialable Java Application"



* Together Control Center  *
* Argo UML *

memory pigs though....

apw
Friday, June 28, 2002

*  Recent Topics

*  Fog Creek Home