Summary
Borland announced that it will re-introduce the Turbo brand of its IDE and compiler products, as part of the company's plans to divest its developer tools into a separate business.
Advertisement
Borland announced that the company will re-introduce the Turbo brand of its IDE and compiler products, focusing initially on C++, C#, Delphi, and the .NET environment. Each tool will be available in a free Explorer edition, and an inexpensive professional upgrade that will also let developers plug in third-party add-ins.
Borland's Turbo line of compilers and IDEs were among the most popular development tools of the 1980s and early 90s. Many developers learned C, C++, Pascal, and later Delphi, using one of these inexpensive, easy-to-use products. It may be hard to fathom a throwback to those simpler times, but Borland believes that the veritable Turbo brand will help mend its image as a developer tool vendor.
In an interview with Artima, Michael Swindell, senior director of product management for the Borland Developer Tools Group, noted that "the Turbo spirit means tools that help make programming fun and accessible, even for beginning developers... We are bring back both the brand and spirit of the Turbos, but with the latest technologies and capabilities."
The initial Turbo products will focus on C++, C#, .NET, and Delphi. "The Delphi and C++ editions will build high-performance native code applications, and the other products build for the .NET and the ASP.NET environments. They have a similar feature set as the professional versions in our Borland Studio environment, and the technologies are all based on the same [code] base. They contain the latest compilers, frameworks, and visual tools. They're just packaged in a single-language pack for the Turbo audience," adds Swindell.
Borland imagines the Turbo audience to be developers who are either just starting out in a language, or those who want to create very rapid solutions, and even non-developer business managers and analysts. Swindell noted that the Turbo products will not compete with other IDEs, such as Eclipse or NetBeans: "A non-developer can sit down with the Turbos, and in five minutes create a form, write a few lines of code, and then compile and run the application. They can be up and running very quickly... With other tools, there's a lot of learning, they're heavy-weight environments. The Turbos, by contrast, are designed to produce results very quickly."
David Intersimone, vice president of developer relations and chief evangelist at Borland, noted that an entire class of accidental developers would like tools that are very different from the Swiss-Army-knife style IDEs used by professional developers. "Maybe you're a working engineer, and you've got a data set and you'd like to [do] some specialized analysis on it that you can't do with a spreadsheet and a scripting language. With the Turbo products, you can easily create a database application, and add a little bit of code. Or maybe you're talking to a piece of test equipment, and you have data from that that you want to analyze. Or some people will have special algorithms that's just easier to specify in a language like C or C++."
The new Turbo tools, which will become available from later this month, are released in tandem with Borland's plans to divest its developer tools business into a separate company. Swindell pointed out that the new company's entire focus will be development tools: "We're creating a standalone developer-focused company that's made up of all the people, technologies, and products that developers are familiar with. The teams, technologies and products behind Delphi, JBuilder, C++ Builder, the heritage, as well many of the people, go back all the way to the original Turbo days in the 1980s. We will focus completely on building products to help developers. We're programmers, we love to program, we have millions of developers today, we want to have millions of new developers. This will allow us to do that. It will also allow us to focus completely on developer tools."
As to how the new company will be able to thrive in an already crowded tools market, Swindell pointed to the desire to focus on making developers' lives easier: "Other vendors in the tools space are really platform vendors. The goal of their developer tools is to bring developers into their stacks. Our goal is to bring productivity and productivity value to developers so that developers get more value out of their development work."
What were your favorite Borland Turbo tools, and what do you think of the company's plans to bring these products back now?
Productivity was the reason I switched to Visual Studio. Visual Studio debugger was so much easier to use. And it had the same features. And that stuff about non-programmers using C or Delphi is a bad bad sign. Maybe they saw Java being sold to managers and thought it was a good idea. I would be far more interested if they made an IDE for Python or Ruby, or better, made scripting available to C++ Builder, so one can make the interface in Python (or Ruby), and the speed critical code in C++. That would be killing. To answer Frank's question, I started to make programs in Turbo C++ 3.0. That was 11 years ago. I even used the 1.0 IDE once. Those are days I don't long for. :)
Any chance that the Turbo C++ offering will be made available on Linux? We are currently using an OpenSource offering (KDevelop) but something like Turbo C++ that natively ran on our development platform would be ideal.
Some years ago, after C++ Builder 6.0, Borland announced a multi-platform C++ Builder, but it was made in Java. I think they dropped it as there's no mention to it on their site. They were going to use wxWidgets for multi-platform user interface, but that was also dropped. I don't know what is happening within Borland, but everytime I hear something about them, they are making some major strategic change. Maybe they're just dying slowly. Does someone know better?
Interesting to see what Borland is doing. I started off with one or two of the Turbo IDEs, and got to like it. When I compared it to gcc (at that time, under MS-DOS, I was pleasantly surprised at its speed, and it allowed me to step through each line of the code I was executing at the time. Then Robert Hoehne brought out his IDE to front-end onto gcc, and I realised I could have my cake for free, and eat it too, though it wasn't as fast as using the Turbo-{C/C++} suites. I'll be willing to try it out if there's a non-Windows binary available for Linux, perhaps even Free/Open/NetBSD. I only have a couple of questions.
Would they be frontending their editor onto the compiler used by Builder? Or would they perhaps patch into gcc toolset? As I remember, it used their own text widgetset, which got recycled into a separate library. Are they still going to use that same editor? Or would they be willing to make it a little more GUI-ified, and make it use native widgets (GTK/QT/Windows Forms)?
Also, how easy would it be for a new developer to actually learn their language of choice using the Turbo IDE, without all the extra windowdressing of needing to design the GUI of the program they're writing too? I personally found it good for concentrating on code, but others may find it restricting that they can't simply "draw" their application into life, a la VisualBasic/VisualStudio, as that seems to be rather a given these days.
I think you are missing the point here. Having one and only one IDE option for Windows development, particularly when its all from Microsoft, is a recipie for disaster. We need lots of options that can provide some competitive threat to MS.
I see the Turbo brand as a brilliant idea. They have the old school guys looking towards this with some joy. And its a brand you can find on the shelves of a computer store. So its able to easily get out to all new programmers, etc. as an alternative to MS products. To me, it signals a revitalization of the Delphi world - long overdue, but done by the right people at the right time.
I suspect Borland's 'DevCo' group will morph into 'Turbo Co' the way this is going. And when they hit the ground, they will have products ready, brand awareness, and the ability to get distribution instantly. I say "GREAT WORK!" and I look forward to another 10+ years of Delphi development.
> Some years ago, after C++ Builder 6.0, Borland announced a > multi-platform C++ Builder, but it was made in Java. I > think they dropped it as there's no mention to it on their > site.
No, it wasn't Kylix. Your link helped me find the name. It was C++ BuilderX. From Wikipedia: "In 2003 Borland introduced the successor to C++ Builder, C++ BuilderX (CBX), which was written using the same framework as JBuilder and bore little resemblance to either C++ Builder or Delphi. This product was aimed at developing large programs for enterprises. However, it did not have commercial success. As a result, Borland announced (at the end of 2004) that C++ Builder will be resurrected and will be part of Delphi development suite. C++ BuilderX was abandoned."
> I think you are missing the point here. Having one and > only one IDE option for Windows development, particularly > when its all from Microsoft, is a recipie for disaster. > We need lots of options that can provide some competitive > e threat to MS. \ > Vlad
Anything Borland puts out for C# and C++ on the Windows platform won't be a "competitive threat" to Microsoft.
What they could do though is to make a really pluggable platform with nice documentation - way beyond what Microsoft has done with VSIP. Think something Eclipse like.
What no IDE vendor seems to be doing is to come up with a better IDE than Visual Studio that' compatible with the Microsoft solution and project file format, for both reading and writing. It is much more difficult to convince a management group to move to a new compiler, especially if the buld system will have to be updated, then to convert one programmer at a time to use their a better IDE, AS LONG AS IT DOESN'T AFFECT THE REST OF THE ORGANIZATION.
I believe that if a better and faster IDE were available that was solution and project file compatible with Visual Studio 2005, more Visual Studio programmers would try it. If they like it, they'll continue to use it. Now, they won't try it. Even if they try it, and like it, many will still not use it for the reasons stated above.
Is project and solution file compatibility really necessary? Wouldn't a import feature do the trick? Maybe you could tell us from your experience why that kind of compatibility would be good. Yes, I want a war story. :)
> Is project and solution file compatibility really > necessary? Wouldn't a import feature do the trick? Maybe > you could tell us from your experience why that kind of > compatibility would be good. Yes, I want a war story. :)
We had enough problems going from VC++ 6.0 to Visual Studio .NET because of imports that we just leave all our old stuff in VC++ 6.0. The main issue is that the newer format is not readable by the older program and in order to be able to maintain all versions of the software we would have to update all the projects. Or leave some older versions in the old tool and the newer versions in the newer tool and then have to manually port changes back and forth because one tool had problems incorporating tools from the other. The problem isn't the source files per-se, but what got especially hairy were any changes to strings, etc. in resource files.
In addition we had some odd problems with certain system calls being depracated and this caused problems with compilation on one or two objects. We could compile them with the older compiler and they still ran fine, which makes me think the calls still have to be available, but the environment worked real hard to make you change them. It was years ago so I can't remember the names of the problematic calls, but the projects were sufficiently old that we were not going to take the time to root out all the calls and update them just to get the compiler ot stop complaining when we could simply use the old compiler.
I can only imagine the pain would be similar with different products from different companies. I would be all for an IDE that could read the VS project files and leave them unmolested. An import means that everybody has to change in one shot. It makes it very hard to try it out to see if it would be any better. What if it's not? Either you are stuck or, best case, you saved all your old project files before the move, go back to those and then reapply the changes you made to the code base. Yuck.
On top of that, the new IDE carried a few quirks that had to be learned. You kind of forget the quirks of the old IDE because they just become "the way you do things" but we had some problems with early editions of VS.NET, especially with regards to integrating source control with web projects.
If you had a small code base or your product wasn't that old I don't see it being a problem. In that case I would do the import and just be done with it. But a full blown import of a product that is a decade or more old and has several hundred thousand lines or more of code, while doable, I don't think would be worth the headache.
Does anyone know if Turbo C++ will be up to the latest standards including the STL? I've heard that boost will be supported. I love using the Turbo tools. My only wish is that they would also offer an update to Turbo debugger, Turbo profiler as well as upgrading TASM to support the latest architecture.
Previous Topic
