Progress vs Microsoft Development Environment.

[ron]

Hi ...

I've worked as a Solaris SysAdmin and Progress DBA (v8 and v9) for the past 13 years. I've written lots of 4gl code - but nearly all to support DBA work. I've not worked in the development of GUI applications at all.

I've just scored a new job, to recruit a new (small) development team to develop several new apps. It is entirely "green field" - there are no legacy apps - no existing h/w.

My (default) instructions are to develop using VB .NET client systems connected to an SQL Server DB. BUT - I have an opportunity to change that - if I can produce "good reasons".

From the little that (I confess) that I know - I'm leaning towards developing VB .NET client apps - but using a Progress DB.

Does anyone have experience with both Progress and SQL Server who can share some wisdom with me as to what would be a good path to follow?

Note - the apps are all for internal use. The largest envisaged would have about 40 to 50 users. None of the DBs are likely to exceed something like 10Gb.

Looking forward to hearing from you!

Ron.

 

[LarryD]

Will the new apps be mainly reporting (e.g. BI) or transactional?

 

[TomBascom]

The new Progress advanced GUI (10.2) is .NET. It's pretty nice.

 

[rusguy]

I've been a Progress programmer since 1996 but I would never choose Progress for a new development these days. If you want to use VB.Net for your UI just use SQL and forget about Progress. MS came up with LINQ that allows you to write for each statements almost the same as you do it in 4GL. The amount of expertise available for MS technologies and amount of tools and controls available for you is limitless. Stop thinking about Progress and move away while you can. Just my thoughts about it, I am sure there will be lots of people who disagree with me.

 

[TomBascom]

I'd rather use a tried and true technology wielded by someone who knows what they are doing

 

[ron]

Larry, the new apps will be highly transactional. The first one will be a "job control" system for a company that hires-out security guards.

Thanks for the feed-back so far. I was hoping for a bit more "meat" - some technical for-or-against points. My experience with Progress is that the database engine is bullet-proof and extraordinarily easy to maintain. I also like the way you can get just about any information imaginable from VSTs. BUT - I don't know whether the same thing applies to SQL Server, or not.

 

[LarryD]

A personal opinion:

The reason I asked is that from my experience, if it was primarily a reporting db, I'd probably lean towards SQL server (or one of the other SQL flavo(u)r databases), especially if it was to be used by Cognos or one of the other reporting tools prevalent on the market.

For transactional, though, it's hard to beat Progress both from leveraging your existing knowledge/experience and ongoing cost of ownership. And Tom is right, from what I've seen the .NET stuff is pretty sweet in GUI.

 

[tamhas]

That stability and ease of use also applies to ABL.

 

[rusguy]

I'd rather use a tried and true technology wielded by someone who knows what they are doing

Exactly my point, I’d rather use a technology that is 15-20 years old and used by many thousands of companies than a technology that is 30 years old and used just by hundreds of companies.
And as for .Net GUI from Progress – can I answer in the same manner? Why use a technology that is so immature yet?

For transactional, though, it's hard to beat Progress both from leveraging your existing knowledge/experience and ongoing cost of ownership.

As original poster said he would hire a new team to build the system – so there is no preexisting knowledge at all, all the knowledge will depend on the team he hires.
Also for transactional/reporting – there are transactions performed in SQL as well.

Don’t get me wrong – I do recommend to use Progress to any shop that has experience with it. But if you assemble a new team – what’s the point to tie yourself to Progress?

 

[TomBascom]

A couple of points spring to mind...

Our original poster has a Progress background and is considering a Progress db.

He may also have contacts with existing Progress developers that he has a trust relationship with.

Mixing a MS front-end with a Progress back-end would not be my ideal. There's a lot to be said for keeping the whole stack consistent.

Progress' .NET GUI isn't a matter of starting with a clean sheet of paper. It is an evolution of a product with a long history. 99% of the language is the same as it was before the .NET UI. It is mostly the availability of a set of controls and an optional tool to manipulate them (Visual Designer -- and it is definitely optional, I, for one, don't use VD). The OO stuff makes it possible to but pre-dates the .NET UI. Language changes directly related to .NET UI are, SFAICT restricted to some data-type conversion stuff and might not even be that.

 

[rusguy]

In my mind use of .Net GUI is good for an already existing application that needs a fresh look and feel, it does allow you to mix old GUI screens with new .Net components. It is the perfect way for existing progress programmers to change something in their app.

But we are talking about something new to build and in my opinion it is much easier and faster to get existing framework written in .Net and build your app on top of that, than writing a new framework for .Net GUI from Progress, learning it in the process because it is so new that not that many people used it for some real development.

From what I understood from the original poster is that the client technology is already decided and it is going to be VB.Net. The only question is whether to use Progress as a database. In this case, Progress DB has no grounds in this setup. Just use SQL, which is natively supported in .Net and be done with it.

 

[TomBascom]

He said "default", not "decided". He has the discretion to change if he has "good reasons".

IMHO the Progress .NET GUI is a perfectly fine tool to use for producing business oriented applications that need to have a .NET look and feel.

The main advantage to doing so, in my opinion, would be that you get to use the Progress 4GL and the Progress Database as part of that solution. The benefits of those two technologies (the 4GL and DB) are either convincing or they aren't. Personally I like them both. Not everyone agrees.

Obviously if you are compelled to be on Microsoft's bleeding edge or if you feel some sort of overwhelming inferiority complex with regards to every cool new UI thingie that comes down the road then you're going to be at a disadvantage.

But I'm usually more concerned with business functionality than technology for the sake of technology and IMHO there is no tool anywhere that makes it easier to express a solution to a business problem than Progress 4GL coupled with the Progress database.

 

[rusguy]

He said "default", not "decided". He has the discretion to change if he has good

reasons.

So, is there any except that he already knows Progress?

every cool new UI thingie that comes down the road

It is very hard to sell an app these days if it doesn’t have all those new UI thingies - Not that many people are happy with character-based or windows 3.11 applications anymore. And a new stuff from Progress – well, it is just way too new.

The benefits of those two technologies (the 4GL and DB) are either convincing or they aren't. Personally I like them both. Not everyone agrees

I like them too, but only in regards of looking at it as some old stuff, like mainframe – which is also old and tried technology.

there is no tool anywhere that makes it easier to express a solution to a business problem than Progress 4GL coupled with the Progress database

I don’t want to sound rude or something, but did you look for any other tools and did you use them for some reasonable amount of time?

Progress used to be a very good technology to build business applications very quickly. Nowadays, all other technologies made this gap very close or at some areas even left Progress way behind. Writing business logic is not a concern if you know what you are doing in any language. Integration with other software, web stuff, web services, reporting tools – everything that you do need to have in a modern application is much easier to build and maintain in MS world. Or you think running proxygen after every change is easier?

And the last, one of the main factors is the amount of tools and expertise available – there is not that much of it available for Progress. So, why bother?

 

[tamhas]

Exactly my point, I’d rather use a technology that is 15-20 years old and used by many thousands of companies than a technology that is 30 years old and used just by hundreds of companies.

Commercial availability of ABL might reach back 25 years, but the product that is available today is hardly 25 year old technology ... it has evolved enormously over that period. Check out ttp://www.oehive.org/VersionHistory ... has Java or C# evolved as much?

And, I think you underestimate the penetration of Progress ... I think the current figure is something like 5 million users on Progress apps ... that's a bit more than hundreds of companies.

 

[TomBascom]

So, is there any except that he already knows Progress?

Sure. All that stuff I said that you're ignoring.

It is very hard to sell an app these days if it doesn’t have all those new UI thingies - Not that many people are happy with character-based or windows 3.11 applications anymore. And a new stuff from Progress – well, it is just way too new.

I mostly agree. Where I believe that we differ is in exactly how close to the bleeding edge one needs to be.

Obviously a nice looking .NET interface is important.

But you do not need to have every imaginable widget. Nor do you need to implement glitzy things the moment MS (or whomever) dreams them up. Often times less is more.

I don’t want to sound rude or something, but did you look for any other tools and did you use them for some reasonable amount of time?

It's a fair question. I often look at other tools and methodologies. But I rarely use them for very long.

I'm wondering how much effort you've put into evaluating Progress' .NET offering. Your dismissal of Progress as being good for nothing but mainframes and character apps suggests "not much".

Progress used to be a very good technology to build business applications very quickly.

It still is. In fact it has gotten better.

Nowadays, all other technologies made this gap very close or at some areas even left Progress way behind.

I'm sorry but I don't see that that is true. I've heard people say it and I've often been at customer sites where it is the official religion but the evidence to support that contention is very, very thin. The only applications that these people are usually able to point to are very small and seem to require an awful lot of care and feeding. They sometimes think that they can use those tools to replace their core Progress applications but, so far, I know of no successful attempts and I can point at some very, very large failures.

Writing business logic is not a concern if you know what you are doing in any language. Integration with other software, web stuff, web services, reporting tools – everything that you do need to have in a modern application is much easier to build and maintain in MS world.

That's crap. Integration with Progress is dead simple. The only people who ever say otherwise haven't actually tried it.

Or you think running proxygen after every change is easier?

You're doing something wrong Probably lots of somethings.

And the last, one of the main factors is the amount of tools and expertise available – there is not that much of it available for Progress. So, why bother?

If you're going to farm everything out to the lowest bidder Progress isn't the tool for you.

 

[rusguy]

Obviously a nice looking .NET interface is important.

Good, this is the start

But you do not need to have every imaginable widget

Not every widget, not at all. But at least some, and it helps that there are so many control extenders out there that you don’t need to worry about writing something on your own. And there are no any limitations, every control is native to the language.

I often look at other tools and methodologies. But I rarely use them for very long.

May be the thought that it is harder to do something in other technologies lays in the fact that you never tried to do the same or never had a training in them? As for me – I don’t have a problem writing both Progress and SQL based code – they are not that different really.

Your dismissal of Progress as being good for nothing

I am not saying it is good for nothing, I am just saying it is not the first pick technology for a new development in a new team. It is still preferred technology in any existing Progress shop.

It still is. In fact it has gotten better.

In fact it did. But comparing to other technologies with similar improvements Progress is very fresh – OO, .Net GUI were part of other technologies for quite some time already, and for Progress it is still relatively new.

They sometimes think that they can use those tools to replace their core Progress applications

It is very hard and probably not a good idea to replace existing Progress app for some other technology. But we were talking about creating something new, that has no baggage of already written code.

Integration with Progress is dead simple. The only people who ever say otherwise haven't actually tried it.

Well, I don’t agree with that. It is not hard, but it is not as easy as with other technologies. I just hate to have too many parts to accomplish something. For example with webservice implementation – I don’t like that I need to worry about wsa, then running app server, having a proxygen – in my mind it should be a part of webspeed with no additional steps to take. And lets not even touch ODBC connectivity.

If you're going to farm everything out to the lowest bidder Progress isn't the tool for you.

Not farm, I am just talking about the ease of getting a new competent resource to join your team.

has Java or C# evolved as much

Hasn’t it?

And, I think you underestimate the penetration of Progress ... I think the current figure is something like 5 million users on Progress apps ... that's a bit more than hundreds of companies.

I just want to see the same number of users for SQL or Oracle. And then multiply it by the number of years a technology used.

 

[TomBascom]

Not every widget, not at all. But at least some, and it helps that there are so many control extenders out there that you don’t need to worry about writing something on your own. And there are no any limitations, every control is native to the language.

So we are in agreement?

Because that's pretty much exactly what Progress' .NET UI is. The one limit being no multi-threading.

May be the thought that it is harder to do something in other technologies lays in the fact that you never tried to do the same or never had a training in them? As for me – I don’t have a problem writing both Progress and SQL based code – they are not that different really.

No, that isn't it. Sure, I don't have much patience for fiddling with stuff that doesn't work, which is badly documented or counter-intuitive and so on. But I have that problem with some of PSC's technologies too

And I have learned and do use things other than Progress.

But when it comes time to put together some code to solve a problem Progress 4GL still seems to me to be much more natural and easy to use than any of the other options.

In fact it did. But comparing to other technologies with similar improvements Progress is very fresh – OO, .Net GUI were part of other technologies for quite some time already, and for Progress it is still relatively new.

Progress has had a GUI for a very long time. Sure, it was ugly but the basic principles are nothing new.

OO trappings are newer but even those can be traced back quite a ways without much effort.

It is very hard and probably not a good idea to replace existing Progress app for some other technology. But we were talking about creating something new, that has no baggage of already written code.

My point was that they don't have any substantial apps built with these technologies. The smart ones realize it.

[]I am just talking about the ease of getting a new competent resource to join your team. [/quote]

If they are smart and capable in the first place, training someone to code in 4gl is no big deal. Whatever environment you're using you should be doing some training to bring people on board and make them effective. The biggest mistake most organizations make is that they do not do so. They just throw people in cubes and let them flail about. Whether they are using C#, Java or Progress 4GL.

 

[rusguy]

So we are in agreement?

Not really

The one limit being no multi-threading.

Multithreading in a GUI environment is very important, isn’t it? And because of that many controls that use multithreading are not really working with Progress.
But this is not the reason I will not use .Net GUI from Progress for a new development – if I need to learn .Net classes, why bother learning it in Progress and not in native .Net?

which is badly documented or counter-intuitive and so on

Do you really think there are less or equal places to read documentation on .Net/SQL than Progress?

But when it comes time to put together some code to solve a problem Progress 4GL still seems to me to be much more natural and easy to use than any of the other options.

This is the most heard argument about using Progress, but I am yet to find the real example. Except of course multi platform capability.

Progress has had a GUI for a very long time

The GUI that Progress had before is from windows 3.11 era. Of course it did (and still does) the job, but it is not sellable at all.

OO trappings are newer but even those can be traced back quite a ways without much effort.

Using persistent and super procedures is not really OO.

My point was that they don't have any substantial apps built with these technologies.

I am sure there are more than plenty of applications utilizing SQL that have database sizes of 10-20gb like original poster wrote. And if you need more and you are not that happy with SQL – use Oracle, there you just can’t say that there are not enough apps available in it.

training someone to code in 4gl is no big deal

I was talking about competent resource, not just an entry level developer. The one that can design and build application, and also mentor others. Also, as for training in 4GL – yeah sure, the easy stuff for reporting and simple character based forms is easy to learn. But I don’t expect a developer with 1 year of experience with Progress to work proficiently with WebServices, app server or sockets. Do you?

 

[tamhas]

Just out of curiosity, what version of Progress are you working with on a daily basis?

And how long ago was the last major architectural revision?

BTW, you have mentioned saleability a couple of times, but I believe the OP is developing something for in-house use. That means "good enough" is whatever they decide it is, not what will make one competitive in a demanding market with lots of competition.

And, training in ABL doesn't equate with entry-level. I'd been developing professionally for 20 years before I taught myself ABL and I have taken experienced developers with good database and algorithmic skills and had them productive in ABL in a short time.

 

[TomBascom]

[QUOTEMultithreading in a GUI environment is very important, isn’t it?[/quote]

Well, no, not really. Certainly not to the point where it should dominate a conversation about the usefulness of a tool.

There is a use case for it and it would be a good thing to have for some purposes but in the grand scheme of things you can do an awful lot without it.

Which isn't to say that Progress shouldn't have it. They should.

And because of that many controls that use multithreading are not really working with Progress.

And just what are these controls? And why would they be relevant to a business application?

But this is not the reason I will not use .Net GUI from Progress for a new development – if I need to learn .Net classes, why bother learning it in Progress and not in native .Net?

How can you tell the difference? Learning the UI classes is pretty much the same either way. It's a maze of twisty little passageways, some all alike, some all different... I've probably spent as much time reading the Infragistics online help as the Progress online help for .NET GUI stuff. The code samples are nearly interchangeable.

Do you really think there are less or equal places to read documentation on .Net/SQL than Progress?

That's not what I was saying. I was saying that .NET documentation is junk.

SQL documentation is slightly better.

This is the most heard argument about using Progress, but I am yet to find the real example. Except of course multi platform capability.

I dunno, there's just something about:

for each customer:
  display customer.
end.

that appeals to me. And so much of the rest of the language just flows so much more smoothly than other languages.

The GUI that Progress had before is from windows 3.11 era. Of course it did (and still does) the job, but it is not sellable at all.

That's lovely but, aside from the color of the lipstick, what does it matter? The concepts of event-driven GUI coding haven't changed in any significant way.

Using persistent and super procedures is not really OO.

The syntax isn't important. The thought process is.

I am sure there are more than plenty of applications utilizing SQL that have database sizes of 10-20gb like original poster wrote. And if you need more and you are not that happy with SQL – use Oracle, there you just can’t say that there are not enough apps available in it.

You're missing my point. Database size wasn't the point. Significance of application is. Mission Critical Enterprise applications aren't built by departmental teams using C# and SQL Server.

It may very well be that our original poster doesn't need a Mission Critical Enterprise application and that's ok. I'm just trying to point out that Progress does have a role to play and some significant tools to offer.

I was talking about competent resource, not just an entry level developer. The one that can design and build application, and also mentor others.

Those people are rare. They are also quite capable of learning whatever tool they need to learn. OTOH if they have a tool (maybe even Progress) that they already know and want to use then it is a very good idea to let them rather than fight them.

Also, as for training in 4GL – yeah sure, the easy stuff for reporting and simple character based forms is easy to learn. But I don’t expect a developer with 1 year of experience with Progress to work proficiently with WebServices, app server or sockets. Do you?

Sure. Otherwise I wouldn't bother hiring them.