Welcome to the MacNN Forums.

dwishbone · Jun 14, 2002, 02:08 PM

Why does it seem like everyone looks down on RealBasic apps and developers? I have used many different programming languages and RB is by far the easiest programming language out there. I know Cocoa is the ideal language for X, but RB is great for Classic/X codevelopement and even for Winblows if you want to. Sure the applications are big...Real needs to work on that...but the apps are not as slow as people claim. It is ultra easy to write software and the apps can be as simple or as complicated as you want.
So people...quit dissin' RB.

Angus_D · Jun 14, 2002, 03:43 PM

I used to really like RB, but I eventually got tired of the slowness of the apps (THEY REALLY ARE SLOW, especially on OS X -- and the IDE is actually unusably lethargic), the bloat, the bugs and the limitations. RB apps CAN'T be "as complicated as you want" - once they get over a certain size/complexity the IDE starts to have problems. Not to mention mostly RB apps don't "feel" right.

Oh, yes, and the company behind it is a bit retarded -- it was claimed that RB 2.5 would run on OS X and be a free upgrade to RB 2 users, but instead it was called RB 3 and cost quite a bit to upgrade to. Now they release point releases quite frequently and waste their effort on such pointless things as "Office Automation" without tackling the underlying issues (like the extremely crappy code generation -- something like 1000 instructions to concat 2 strings together, or more, I'm not entirely sure).

This is all from my own personal experience, but I also know several other people who have had similar experiences to me, so I know I'm not alone. My advice is to get out of RB before you've invested so much time/effort that it'd hurt you to do so.

absmiths · Jun 14, 2002, 03:49 PM

Developers generally come in two camps - 1) those that like visual GUI environments like VisualBasic and RealBasic (and InterfaceBuilder to some extent) and 2) those that do everything in a text editor and rely on a good IDE simply for managing build targets, providing a nice editor, and using projects to bundle options and source files.

I personally prefer the latter since in my experience the nice visual environments will leave something to be desired and the workarounds will be painful and the bug fixes slower than molasses in winter.

I also disapprove of MS's characterization of developers as monkeys who just need the right tool to be able to be productive.

Ibson · Jun 14, 2002, 09:49 PM

<blockquote>quote:<hr />Originally posted by absmiths:
Developers generally come in two camps - 1) those that like visual GUI environments like VisualBasic and RealBasic (and InterfaceBuilder to some extent) and 2) those that do everything in a text editor and rely on a good IDE simply for managing build targets, providing a nice editor, and using projects to bundle options and source files.<hr /></blockquote>I suppose I fall into the first category, as I am primarily a designer who actually got into programming to manage projects and such. I started out in RealBasic in OS 8 & 9, and found it acceptable there. It was when I switched to X full-time that I found RealBasic unacceptable. My main concern was that the interfaces one could create in it were *shocking*. I spent almost all of my time in RealBasic trying to emulate Cocoa elements such as toolbars and Quartz smoothing across-the-board. One day, I opened up Project Builder and started, and although it was rather confusing at first, I quickly became used to Cocoa and its power. The applications built were smaller, faster, cleaner, and the interfaces were decidedly more elegant. I think many people realize this and therefore hate RealBasic.

Also, among the user community, many people have used crappy (for want of a better word) RealBasic programs. These programmers are generally lazy, or simply tasteless�and the UIs they create are shocking.

I'd have to agree that REAL Software is pretty retarded. As Angus_D said, get out of RB before you've invested too much money in it. Project Builder and Interface Builder are *free* and a hell-of-a-lot more powerful. Please, use those.

SoClose · Jun 15, 2002, 02:03 PM

One problem with RB is that in reinforces the script-kiddie stigma of scripting languages (like REALbasic or Visual Basic) wrapped up into application shells. For even simple apps RB produces a huge binary, which is just unacceptable. It's fine for some simple tasks, but you're at the mercy of the RB runtime when it comes to performance tuning. Granted, there is a huge learning chasm to be crossed when going from RB/VB to something like Objective-C, Java or C/C++, but those languages are the ones that will drive commercial and professional development. I try to provide the smallest binary and highest possible performance I can. Given Mac OS X's prediliction for Mach-O binaries and Cocoa and Carbon's optimization, writing in a C-based language was just a no-brainer for me. I wrote a bunch of stuff in Cocoa-Java, but wasn't happy with performance and the design of the Cocoa API set doesn't really lend itself well to Java.

davecom · Jun 15, 2002, 07:42 PM

First let me say that I agree with your criticism of RB, and that I haven't used a recent version of it since 1999. However, in today's world of increasing disk size and bandwidth, the argument that the 1 MB executables that RB produces for simple applications being too big, is becoming tired. However the bugginess and sometimes reported slowness(I never found this to be the case) need to be worked on. In conclusion, I'm happy we have as good of a competitor to Visual Basic as we have.

parallax · Jun 16, 2002, 11:44 AM

In a nutshell, RB apps are slow, bloated, and buggy, Basic is a horrible language, and with the ease of Cocoa (ObjC, once you learn it, is a much cleaner language than Basic) there's very little point in using RB.

Mactoid · Jun 16, 2002, 12:12 PM

<blockquote>quote:<hr />Originally posted by davecom:
First let me say that I agree with your criticism of RB, and that I haven't used a recent version of it since 1999. However, in today's world of increasing disk size and bandwidth, the argument that the 1 MB executables that RB produces for simple applications being too big, is becoming tired...<hr /></blockquote>I haven't used it in over a year either, however I must say I never had any real problem with bugs in the IDE, however I did and still do have a huge problem with the size of the binaries. I don't agree that todays huge hard drives make up for the big programs. Sloppy code is sloppy code. What could have been done in 512k 10 years ago should still be done in 512k.

davecom · Jun 16, 2002, 02:36 PM

<blockquote>quote:<hr />Originally posted by Mactoid:
 <blockquote>quote:<hr />Originally posted by davecom:
First let me say that I agree with your criticism of RB, and that I haven't used a recent version of it since 1999. However, in today's world of increasing disk size and bandwidth, the argument that the 1 MB executables that RB produces for simple applications being too big, is becoming tired...<hr /></blockquote>I haven't used it in over a year either, however I must say I never had any real problem with bugs in the IDE, however I did and still do have a huge problem with the size of the binaries. I don't agree that todays huge hard drives make up for the big programs. Sloppy code is sloppy code. What could have been done in 512k 10 years ago should still be done in 512k.<hr /></blockquote>Yes but sloppy code by Real Software, not RealBasic binaries. I'd be interested to know the disk usage of average Visual Basic apps versus Real Basic apps. Perhaps in RAD high disk usage is a necessary evil.

Mactoid · Jun 16, 2002, 03:18 PM

<blockquote>quote:<hr />Originally posted by davecom:
Yes but sloppy code by Real Software, not RealBasic binaries. I'd be interested to know the disk usage of average Visual Basic apps versus Real Basic apps. Perhaps in RAD high disk usage is a necessary evil.<hr /></blockquote>sloppy code by Real Software -> sloppy compiling -> sloppy binary

Not to mention the size of the built in functions as angus_d mentioned. I can't speak for all VB apps, but they are in general much smaller. <a href="http://hyposphere.net/code/MatchingGame.exe.gz" target="_blank">Here</a> is a game I wrote in VB a while ago. It's a simple game, and it's a very modest size application.

Compare that with a trivial "Hello World" app in RB which is still close to 1MB.

I though that VB used to make such small apps by putting standard functions in a separate and very large dll that was required for the program to run, however I just tried that matching game on my father's PC and it ran fine. I'm pretty sure he has no VB dll installed.

PS: if that first link doesn't work, try <a href="http://homepage.mac.com/peterm/MatchingGame.exe.gz" target="_blank">this</a> one. A storm is brewing and it may knock out my power pretty soon

[ 06-16-2002, 04:25 PM: Message edited by: Mactoid ]

SoClose · Jun 17, 2002, 09:01 AM

<blockquote>quote:<hr />Originally posted by davecom:
First let me say that I agree with your criticism of RB, and that I haven't used a recent version of it since 1999. However, in today's world of increasing disk size and bandwidth, the argument that the 1 MB executables that RB produces for simple applications being too big, is becoming tired. However the bugginess and sometimes reported slowness(I never found this to be the case) need to be worked on. In conclusion, I'm happy we have as good of a competitor to Visual Basic as we have.<hr /></blockquote>Ack...I don't agree. I only have a dial-up connection at home (don't get me started on the lack of broadband roll-out) and greatly appreciate developers who create free/shareware in the smallest possible package. Just because I have a 40GB hard disk, doesn't mean that it's OK to produce bloatware. I wish that REAL Software would figure out a way to deliver the RB runtime like Apple does -- as a shared Framework. RB developers could then have the option to deliver the runtime with their application or not. A small checker included with every compiled RB app could check the existing system runtime and then decide whether it's suitable for running the current app or would promp the user for an update to the framework. If the framework is just the RB interpreter and some other support files, it would have to be updated far less frequently than the IDE.

I am glad that Macintosh developers finally have a plethora of development environments to create applications. I would argue that looking at the situation, combining RB, AppleScript Studio, JBuilder, CodeWarrior and the large amount of open source IDEs (i.e.: NetBeans), development on the Mac has never looked so good. However, RB needs to sustain its place as a cutting edge RAD tool by taking steps to make optimized binaries. VB is a classic example of producting bloatware, not just in code size but in the amount of support files its binaries require and the DLL hell it creates. Let's not make or accept the same mistakes as Microsoft in the Windows world!

Millennium · Jun 17, 2002, 11:22 AM

There's another issue which hasn't been addressed yet.

An easy-to-use programming language is, generally, a Good Thing. However, it's possible for a programming language to be too easy for its own good. By this, I mean that it gets people into coding apps before they've learned good programming techniques, or even the basics of interface design. This leads to a glut of subpar apps, and people start blaming the language for it. That's not really fair, but it happened with HyperCard, and it happened with VB, and now it's happenning with RealBasic.

Also, packaging the RealBASIC runtime as a shared library might not be the greatest idea. This is how VB is distributed, and it has caused its share of problems in the past. In particular, there are problems with mutually-incompatible versions. This has led to many people distributing the runtime with their apps, which in turn breaks other apps, and it becomes a huge mess. Rolling the runtime into the OS is a tradeoff; it makes for larger binaries, but apps won't interfere with each other. Is the tradeoff worth it? Perhaps.