New topic: Open Letter To REAL Software
<http://forums.realsoftware.com/viewtopic.php?t=29181> Page 1 of 1 [ 10 posts ] Previous topic | Next topic Author Message NeXTLoop Post subject: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 5:39 pm Joined: Fri Oct 28, 2005 9:30 am Posts: 58 Hi Everyone, Having just used RB for a very large commercial product (not to mention being an RB developer since 1999), I've become increasingly frustrated with RB. I sent an email to an individual at RS, but thought I'd post a similar version of it here in the form of an open letter. As you can see from this email, I am not ranting, venting, or throwing a fit. Nor am I falling into the category of individuals who run into one thing that doesn't work the way they want and immediately proclaim that they're abandoning the environment. Quite the contrary... I have worked through numerous major issues, and continue to do so. I am gravely concerned, however, that with these kind of issues RB may cease to be a viable option for my company moving forward. Even worse, if my company is experiencing these kind of problems... how many other uses may RS be risking for similar reasons? <<BEGIN OPEN LETTER>> Dear REAL Software, Thanks for checking with me regarding RB 2009. Unfortunately, we won't be upgrading to this version. Having used RB since 1999, I have to say that using RB has become increasingly frustrating. RB was used to create the MailForge email client (designed to be a replacement for Eudora). While originally chose for its cross-platform capabilities, actually using it for this type of application has been an exercise in frustration. If you don't mind, I'll list a few things that been major problems (and I apologize in advance for the length of this): 1) SMTP Sockets (I'm actually working on this right now) A large percentage of SMTP servers that require SSL first require you to connect insecurely and then, once connected, negotiate a secure connection. The problem? RB's sockets have no support for changing the encryption state mid-connection. Here's what I don't understand..... Given how widely used this setup is, why wasn't support for it included? Aaron Ballman wrote on the NUG back in 2004 that this was a known issue... yet still no fix. At this point I'm looking at having to write a Perl or Ruby program to offload mail sending in these situations. This is definitely less than ideal, given that I'll have to make sure Perl or Ruby is installed on Windows machines that MailForge is installed on. 2) Shell Use On Windows The problem could be solved by using a Shell... except that Shells don't work very well on Windows. Even when set to interactive mode, they're notorious for not giving feedback as to what they're doing, making using them in this case impossible. 3) POP3 Socket Buffers When using the built-in POP3 sockets, if you download an email larger than 1 or 2MB, the download starts slowing down exponentially. To make matters worse, the program will start taking 90% CPU and render your program unresponsive until the download completes. The reason for this is due to the buffer that email data is being saved to being a simple string. Any RB programmer knows that the more data you append to a string... the longer it takes with each append, the slower it becomes. So why exactly was a basic string used as a buffer for something like emails, where the size can easily be 2, 5, 10, 15MB or more? In this case, it was necessary to write a completely new POP3 Socket from scratch, properly utilizing an array of strings to ensure that performance stays as it should. 4) EmailMessage Class There are so many problems with the built in EmailMessage Class that its hard to know where to begin. It doesn't properly handle multi-part embedded MIME messages. If a person sends a text file as an attachment, the EmailMessage class will discard any text portion of an email and use the text file as the email body instead. On outgoing emails (this issue shares responsibility with the SMTP socket), its impossible to send with any Content-Transfer-Encoding other than 8bit if you're sending a multi-part message. Needless to say, this is another area where it was necessary to write a custom EmailMessage class from scratch just to have basic functionality that should have already been addressed in the built in class. 5) HTMLViewer There are literally so many issues with this control that its not even worth going into any detail. Again, these issues have been widely reported, acknowledged by REALSoftware, and largely gone unaddressed. The above examples are just a few of the maddeningly frustrating things experienced when developing MailForge. The list is actually considerably more extensive. What makes each of these so frustrating is that, in each case, they've been known issues for years... with no fix. In addition to that, these issues are not unreasonable expectations. If a development environment advertises that it has SMTP capabilities, one would not expect it to break on roughly 30% of servers... let alone be nearly impossible to fix internally. If a development environment advertises POP3 support, one would not expect it to be completely useless on anything over 1 or 2MB, necessitating the need for a completely custom socket. One would not expect a development environment to completely mangle incoming messages, if it previously advertises the ability to parse email messages. In many cases, using features in RB is like buying a car with a steering wheel that only makes right hand turns. It works great if you only need to make right hand turns. If, on the other hand, you need to make left hand turns (not at all an unreasonable idea) you either need to completely engineer your own steering wheel or, worse yet, get something external to help you make the left hand turn. I can't tell you how many days, and even weeks, of work has been lost tracking down why something isn't working, only to come to the realization that those days (or weeks) of work are now useless, since its going to be necessary to write something from the ground up. Having said all of the above, I keep trying each new version of RB in the hopes that at least some of these things are addressed. We really do want to keep using RB. We have zero desire to move to another development option. But needless to say, I have a hard time imagining continuing to run into issues of this magnitude working toward version 2, 3, 4, etc. And, as a company, we certainly have no desire to deal with issues like this over the coming years. As I said at the outset, I apologize for the length of this email. I simply want you to have a clear picture on why I won't be upgrading to RB Studio for the foreseeable future. If these kind of problems are experienced, on what should be a relatively straightforward application of this development environment (not to mention with a decade of experience with the environment) I can only imagine that similar experiences are costing REALSoftware other sales as well. I welcome any input or feedback. Sincerely, -- Matt Milano Project Manager Infinity Data Systems, LLC Top computerfreaker Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 6:16 pm Joined: Thu Mar 05, 2009 1:03 pm Posts: 1123 Location: USA NeXTLoop, your letter sounds much like our recent petition to RS... http://forums.realsoftware.com/viewtopic.php?f=9&t=28949 Yet another example of a frustrated developer pleading for bug fixes... why does this sound so familiar??? _________________ Learn something new every day, and the rest will take care of itself. Life is a journey, not a destination. Enjoy the trip! Top Karen Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 7:31 pm Joined: Fri Sep 30, 2005 8:53 am Posts: 584 NeXTLoop wrote: The reason for this is due to the buffer that email data is being saved to being a simple string. Any RB programmer knows that the more data you append to a string... the longer it takes with each append, the slower it becomes. So why exactly was a basic string used as a buffer for something like emails, where the size can easily be 2, 5, 10, 15MB or more? That is likely because it was a quick and dirty implementation coded in RB itself, but doing something an experienced RB programmer should know not to do for general usage (though it could be fine for situations you know emails will always be small and simply text). That with immutable strings, such concatenation can be very slow , is something every RB coder knows. You may remember when Array.Join was first introduce it was obviously coded under the hood as a simple RB string concatenation (or it's equivalent ). When it was obvious Join was slower than Charles' string concatenation code and about the same speed we would get for simple RB string concatenation ourselves, a number of us complained and RS fixed it... But that was something more widely used than the Email classes Anyway it's that type of thing ( appearing to add features just to advertise they have them without worrying about doing a reasonably complete implementation reasonably coded for general use job) along with bugs that historically have been what has gotten people upset with a RB. Amateurishly implemented features like that are very much a huge time trap ... particularly as when doing initial feasibility testing they look reasonable, and why so many advise using RB only for small projects.. and something that needs to addressed quickly if they wish to be able to sell new people on Studio and then KEEP them using RB. - Karen Last edited by Karen on Wed Jul 22, 2009 9:53 pm, edited 1 time in total. Top Jonathon Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 8:17 pm Joined: Fri Sep 30, 2005 5:54 pm Posts: 1723 Location: Great Falls, Montana USA You know? I was think as I read the posted open letter of one companies slogo... Nike with... Just do it! We should have one for REALbasic... Just fix it! _________________ Jonathon Software Devlopement: http://www.medalertpc.com Surplus Hardware: http://www.semielectronics.com RB2005 R4 Pro for Windows XP Pro/SP2 Top NeXTLoop Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 9:26 pm Joined: Fri Oct 28, 2005 9:30 am Posts: 58 Karen wrote:Amateurishly implemented features like that are very much a huge time trap ... particularly as when doing initial feasibility testing they look reasonable, and why so many advise using RB only for small projects.. and something that needs to addressed quickly if they wish to be able to sell new people on Studio and then KEEP them using RB. - Karen This is exactly what we've experienced. So many features that seem very promising, and let you implement 90% of what you're trying to do... only to be completely foiled at the last 10%. Our team has literally wasted WEEKS dealing with issues like this. RS either needs to implement features completely, don't implelment them at all, or if they do partially implement them... warn us that they're partially implemented. Let us know that [insert feature here] is not completely implemented. That way we won't waste time working with it... only to find out how crippled the feature actually is. Top Mo_Funds Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 9:45 pm Joined: Fri Sep 30, 2005 3:29 pm Posts: 589 NeXTLoop wrote:This is exactly what we've experienced. So many features that seem very promising, and let you implement 90% of what you're trying to do... only to be completely foiled at the last 10%. Our team has literally wasted WEEKS dealing with issues like this. @ NeXTLoop, Karen and ComputerFreaker : That has been my many experiences over the years using REALbasic Pro. That is exactly why I get so pissed off at the never ending bug problems in REALbasic and post about the bugs. NeXTLoop wrote:RS either needs to implement features completely, don't implelment them at all, or if they do partially implement them... warn us that they're partially implemented. Let us know that [insert feature here] is not completely implemented. That way we won't waste time working with it... only to find out how crippled the feature actually is. @ NeXTLoop, Karen and ComputerFreaker : Yes. I agree. Fix what you already have and don't add new things that don't work. Thank you for writing your post and sharing your letter. @ Jonathon - I like it! I like it A LOT! Quote:JUST FIX IT! _________________ Intel MacBook Pro OS X 10.5.7 RB Pro. Top ChickenScratch Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 11:02 pm Joined: Fri Feb 15, 2008 5:14 pm Posts: 43 I have read in other parts of the forum where people say that they like for RB to continue adding new features, thus justifying their subscription fees. I, like the others on this thread, don't give a "hoot" about new features UNTIL a true and stable version of RB is released. I don't mind paying a yearly subscription as long as I know bugs are getting squashed (btw, my biggest beef is with the HTMLViewer - been buggy forever, yet has so much potential for inclusions in so many projects). I don't want to pay a subscription fee just to have the newest and coolest feature, which in itself introduces new bugs that will never get fixed. This is the reason why I am still stuck with RB2008R1. I started a pretty big project with this version and have tried newer versions only to find some parts of my project no longer work or compile properly. With large and on-going projects, no one in their right mind would switch to a new build just because it has a bigger number or newer toys. There are only a handful of companies that manages to continually release buggy software and get away with it. Hopefully RB will get out of this club and maybe RB might have a chance at becoming an accepted and respected dev environment/tool that it is capable of becoming. Until a stable version is realized, I doubt I will ever renew my subscription. And to pour salt onto an open wound, changing the name REALBasic to something else won't make a difference (this is in reference to a recent post about wanting to change the REALBasic name). People (new and current users) will eventually see that it's a wolf in sheep's clothing and just give up and leave. Top NeXTLoop Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 11:08 pm Joined: Fri Oct 28, 2005 9:30 am Posts: 58 ChickenScratch wrote:This is the reason why I am still stuck with RB2008R1. I started a pretty big project with this version and have tried newer versions only to find some parts of my project no longer work or compile properly. We're in the same boat. My company actually did a very large contract job for a California University involving astronomical image manipulation. We developed it using RB 2008... only to discover it won't even compile with 2009. I've been working with the University's in-house programmer trying to migrate the code... as if I'm not already pulling out my hair due to the problems we're having with MailForge development. Top NeXTLoop Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 11:16 pm Joined: Fri Oct 28, 2005 9:30 am Posts: 58 ChickenScratch wrote:...maybe RB might have a chance at becoming an accepted and respected dev environment/tool that it is capable of becoming. Until a stable version is realized, I doubt I will ever renew my subscription. You hit the nail on the head. RB has tremendous potential. It could easily accomplish so much more than it has, and be so much more widely used and respected than it is. But not as long as features are added with the, seemingly, sole purpose of being able to say "we've now added this too"... and very little regard to making sure it works in all the ways it should. As I indicated in my email, we simply cannot justify upgrading when all these issues still sit unresolved afters years of being reported and acknowledge by RS. I can't imagine moving into version 2,3,4, etc and still dealing with this. Last edited by NeXTLoop on Thu Jul 23, 2009 12:43 am, edited 1 time in total. Top paulg Post subject: Re: Open Letter To REAL SoftwarePosted: Wed Jul 22, 2009 11:42 pm Joined: Thu Oct 05, 2006 11:45 pm Posts: 429 Location: Planet Earth:North America:California @NeXTLoop, That is a very well put together, professional email, +10 kudos! I think you said something that has hit home with me. I mostly have worked on small projects here and there that have seen very little issue, well except the addressbook class bug that put a stop to one project. With small projects, like mine have been, RB has been a great tool. But seeing how some of the professional developers are using it in large projects and finding unimplemented or poorly implemented features is not good at all and must be addressed. Unfortunately a little bug that makes one aspect of one of these advertised classes not work ruins the whole class and it seems to make these features useless. If that is the case for email, smtp, http_viewer and AddressBook, then we need some fixing here. Some things I have seen that are the cause of OS and or system bugs, but the few I have tested this week seem to be clearly RB bugs. So, like Jonathon said, "Just Fix It!" We all want the same thing: A great development tool that grows well with the users and works as advertised. -Paul _________________ This message made with 100% recycled pixels. MacBook CD2.0/2GB/OSX 10.5.7 / RB Pro 2k9R3 Top Display posts from previous: All posts1 day7 days2 weeks1 month3 months6 months1 year Sort by AuthorPost timeSubject AscendingDescending Page 1 of 1 [ 10 posts ] -- Over 1500 classes with 29000 functions in one REALbasic plug-in collection. The Monkeybread Software Realbasic Plugin v9.3. http://www.monkeybreadsoftware.de/realbasic/plugins.shtml [email protected]
