Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

With what tool/language will Desktop Apps be developed? 1

Status
Not open for further replies.

jsteph

Technical User
Oct 24, 2002
2,562
US
For the Windows world, I'm curious to know what the conventional wisdom is as to what major tools/languages will be used in the next 5-10 years or so for desktop app development. Or will 'desktop app' be an obsolete concept, with everything going towards Web apps or Web services or subscription apps?

I ask because what I see and have heard, is that for Windows, the .Net has not taken off well for Desktop Applications. In my experience, I still see a lot of traditional VB, some C++, and some Delphi, Powerbuilder, and some of the other 4gl's of the '90s. I'm just wondering if any or all of these will be considered 'dead' in 5 years?
--Jim
 
The foundations of these three languages were developped first halve of the 80's. you could walk in any university library anywhere in the world, and find a book about C, Pascal, Basic and Fortran, or a book about programming with examples in one of these four langauges.

As long as the basic problem:
1) Enter 3 numbers
2) Choose the largest
3) Print out the smallest
cannot not be written with mouseclicks, the basic languages will exist.

Do you think that all these professionals who learned to use the language to resolve real world problems, will throw all this knowledge away in favor of some marketing hype?

Programming is not drag and drop.

Steven van Els
SAvanEls@cq-link.sr
 
I think I could do that with mouse clicks in Excel. But Excel had to be written first. :)



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!
 
Well, with Microsoft upping the emphasis on thick rich clients, and what you could term the "plateau-ing" of presentation/interface technologies in thin-client languages - I think you'll see pretty much the status quo for the next five years.

Desktop development will continue to be split pretty much as it is now. I would see more effort going into putting 64-bit Windows through its paces first.
 
If desktop apps do become extinct, how will the web based applications run (they need a browser, which is a desktop application)?
One possibility is that desktop PC's or similar become pure web browsers with an internet connection, but this removes flexibility - and what happens when the internet connection goes down, as it will occasionally?...

John
 
but this removes flexibility - and what happens when the internet connection goes down,
Yes, this was part of why I was curious. Web apps are Single-Doc-Interface, which is, in my opinion, extremely clunky, and I know that where I work, we don't want all desktops connected to the internet--only to our local network.

I'm glad I'm not the only one who sees that while the web, and web apps, are usefull, it's not the end-all, be-all.
--Jim
 
None of the languages you mention will 'die'. They will fade or morph however. Even COBOL is alive and well. There is a version of COBOL being developed to run on .NET and that is the future. The .NET architecture and the Java architecture are very similar. That is the model for the future of general purpose programming.

There is no reason for business code to need to do pointer indirection or bit-mask manipulation. The automatic bounds checking and garbage collection of modern languages are one of their most valuable features.

There are two main reasons .NET haven't taken off yet. One is high entry cost. Yes, the .NET SDK is free and SahrDevelop is now out there but most people will want VS.NET and that is expensive. As the new single language hobbyist versions of VS come out with 2005 yuo will see a lot more people dabbling in .NET.

The second issue is that there are a lot of procedural programmers out there that don't want to or just won't learn object oriented developement. VB.NET and VB6 are completely different animals, yet there are tons of VB6 folks who struggle mightily to try and use VB.NET like VB6, then finally fail, deciding there's no advantage to upgrading.

Mind you, I'm not talking about high performance games or real-time machine control programming, there's plenty of use for lower level programming in those arenas among others. I'm talking about mainstream n-tier business programming. In that area, .NET or .NET style programming will gradually increase. It'll take time but there's a lot of inertia out there.

[sub]Jeff
[purple]It's never too early to begin preparing for [/purple]International Talk Like a Pirate Day

I was not born cynical - I earned my cynicism through careful observation of the world around me.[/sub]
 
Currently, its a buyers market for software.

Smaller companies can hire good programmers at a reasonable price. Smaller companies don't really use the internet as much so the desktop application is far from dead. Plus with the rapid deveolopment and office integration .Net offers great tools for programmers working in this enviornment. Adoption will continue to be slow, but I feel that 3yrs is a reasonable time frame to see a lot more development in this area.

As far as languages dying, not going to happen. IT expendetures are not going to allow change of language, and new killer aps dont seem to be on the horizone(in a five year timeframe anyway)



if it is to be it's up to me
 
As the growth of Linux on the desktopn continues, .NET will have a higher hurdle to jump.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!
 
As the growth of Linux on the desktopn continues, .NET will have a higher hurdle to jump.

Actually, I think this is true at the server level, but not the desktop. LAMP servers do pose an entry barrier to adoption of ASP.NET.

Desktop Linux I think is beginning to face serious evaluation (moving out of the "interesting") phase and is getting devalued on the support end. Any org can find good Wintel support, and can reasonably evaluate the bona fides of that support; not yet true with Linux. Anecdotal, but that's the consensus among my ad-hoc peer group that meets for lunch.
 
As the growth of Linux on the desktopn continues, .NET will have a higher hurdle to jump.

Not necessarily. One of the things on my "to do" list at home is to get Mono running on the Mac mini. I have it downloaded, just haven't had time to install/configure it.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
...tons of VB6 folks who struggle mightily to try and use VB.NET like VB6, then finally fail, deciding there's no advantage to upgrading
And in my opinion, they may be right. Supposing MS continues to fully support the win32 api indefinitely, from what I've seen there may be no advantage to converting existing VB6 (or delphi,powerbuilder, or whatever) business apps to .Net.

I've seen some huge enterprise VB6 apps which use VB6's version of classes and objects, though not to the full advantage. Yet the apps work and are maintainable. What would converting to .Net do besides cost a lot of money and render useless the development staff? That last point I think is certainly one of the things that is keeping vb6 alive.

In my case, I'm learning .Net, if only to hedge. Our enterprise has a good deal of VB6 out there and I certainly won't recommend converting just because it's the latest trend. I've been formally trained in C++, and I 'get' the whole object philosophy. But even when I consider myself reasonably fluent in .Net, I may not see the need to convert. However, if MS either intentionally or insidiously torpedoes win32 in a future release to which we are compelled to upgrade, then my hedge will have paid off.
--J
 
For now Windows desktop development is still done pretty "traditionally" using tools targeting Win32. WinForms has had a rough start trying to get off the ground, and with Avalon in the offing we're looking at another big flip in terms of UI development.

Many of those Win32 tools are indeed getting long in the tooth, with the possible exception of Microsoft's C++ for the 21st Century editions of Visual Studio. I'm not sure Borland will stay in position long as a Win32 tools supplier.

Web application development does not necessarily mean public Internet development. In even medium sized business environments loss of access to mail and file servers pretty much shuts workers down anyway. This means client/server "web" or "web service" based applications dependent on central servers in the organization do not bring any novel risk or hardship.

A few options look interesting for line of business desktop development.

REALbasic has strong Mac origins, but supports development on both Windows and Mac machines and targets Mac, Linux, and Windows. Its biggest drawback on first glance seems to be the weak IPC options it offers. There is little COM support, possibly no DCOM (no common Mac/Linux analog anyway), and it seems to rely on a very primitive client/daemon via raw TCP or UDP model.

Of course it seems like it would be easy to create a class that supports XMLHTTPRequest functionality. This might make it good for developing multi-platform clients that connect to a .Net, Java, or whatever back end or mid-tier application. Such classes are probably already out there for REALbasic, I don't know that market at all.

It seems a little weak in the database area as well, perhaps I just don't know enough about it. When developing for SOAP-like client access protocols though, I suspect all you'll want or need is a decent set of XMLDOM classes to use within your client code. The data access layer will live on a server. These may also be available today.

Avalon appears to be a revival of the old HTML Application (HTA) concept that came to life with IE 5. Microsoft seems to have turned its back on HTAs, but there are some strong parallels in Avalon. Regular HTML seems to have been replaced by "XAML" markup while JScript/VBScript is replaced by C#/VB.Net.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top