Progress vs Microsoft Development Environment.

[rusguy]

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

Hm, and how is it relevant to the discussion on what to use for a new development? I am usually using whatever the current client uses, currently on v9.1d, before that was 10.1 something, before that was a mix of v9 and v10.

I believe the OP is developing something for in-house use

Don’t you need to sell it to the upper management?

I have taken experienced developers with good database and algorithmic skills and had them productive in ABL in a short time

Productive yes, but they don’t become experts and do everything people in a short time.

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

Don’t you use a timer within your app? So any control that has a timer is not usable. And you do need a timer just to refresh a screen from time to time.

Learning the UI classes is pretty much the same either way

Learning classes is the same, but while you are learning those classes you are reading samples in c# or vb.net code, and then try to do the same in progress, hence learning more than 1 language at the same time – and why do you need to do it?

I was saying that .NET documentation is junk.

I completely disagree with that. I consider MSDN docs to be pretty well organized and integrated well enough. Also don’t forget about power of google J

I dunno, there's just something about: for each

Oh, the infamous for each. Well it doesn’t differ much from select * from customer. But we are not talking about character applications. I thought we are talking about windows gui client, where regular for each is used only to get multiple records from db and do something with them later on. Or if you do insist on the use of for each here is a c# code:
Foreach (Customer c in Customers)
{
console.writeline(c.name);
}

And so much of the rest of the language just flows so much more smoothly than other languages.

This is just because you are used to it, but it doesn’t matter it is better or worse.

The concepts of event-driven GUI coding haven't changed in any significant way.

Of course it didn’t, the same way as general concepts of programming haven’t changed for ages

The syntax isn't important. The thought process is

True, that’s why I am still to find the reason to write something in the new OO except when you would need to do something with .Net GUI.

Mission Critical Enterprise applications aren't built by departmental teams using C# and SQL Server.

I am sure half of the Wall street companies will be very interested in this conclusion

it is a very good idea to let them rather than fight them.

Usually it is us, Progress people, who fight to let our technology in, not the other way around

Otherwise I wouldn't bother hiring them.

I had quite a different experience – from 4 out-of-college kids trained with Progress 0 left in the technology within 1.5 year.

 

[TomBascom]

The version of Progress being used would be relevant to several aspects of the conversation. In particular those about integration and modern GUI controls. Complaining that Progress doesn't support .NET very well, for instance, is silly if you are using V9 as a yard-stick.

Don’t you need to sell it to the upper management?

Usually you need to sell business value to upper management. If you are selling look and feel you probably don't have any business value.

Don’t you use a timer within your app? So any control that has a timer is not usable. And you do need a timer just to refresh a screen from time to time.

Sometimes. But it doesn't require multi-threading to do so and you definitely don't need to use a timer just to refresh a screen. (Progress has supported PSTimer in GUI environments since v7...)

I'm not sure what you mean by a control that "has" a timer. A timer is a control and it generates events. Associating those events with particular controls is what the event handler does. But unless I'm missing something I don't see that a button, for instance, "has" a timer.

Learning classes is the same, but while you are learning those classes you are reading samples in c# or vb.net code, and then try to do the same in progress, hence learning more than 1 language at the same time – and why do you need to do it?

So replacing a ":" with a "." is some sort of enormous burden? Have you actually tried working with the Progress .NET GUI?

As for the quality of the .NET documentation it is horrible. It is filled with circular references, incomplete explanations, half witted examples and utterly pointless drivel. And then when you Google stuff 99% of the results are crap. The amount of time wasted is monumental.

Oh, the infamous for each. Well it doesn’t differ much from select * from customer. But we are not talking about character applications. I thought we are talking about windows gui client, where regular for each is used only to get multiple records from db and do something with them later on. Or if you do insist on the use of for each here is a c# code:

foreach (Customer c in Customers)
{
  console.writeline(c.name);
}

Well, actually, there is alot of difference. The point, which you have nicely illustrated thank you, is that the Progress code is simple, clean and english-like. It is easy on the eyes and pleasant to read. The C# code is gobbledygook. Relatively speaking.

It is not just because I am used to it either -- it is objectively true that the 4GL uses more english-like constructs than C#, Java, VB or whatever.

And, no we are not talking about character applications. We're talking about business applications.

The english-like syntax has considerable value. The less distance there is between the code and the problem domain the less opportunity there is for miscommunications and errors.

 

[tamhas]

Hm, and how is it relevant to the discussion on what to use for a new development?

Because it speaks to the experience base from which you are speaking. In particular, working with customer code architected in the 80s is unlikely to provide exposure to modern best practice techniques, even if the application is actually running on a reasonably modern version.

Don’t you need to sell it to the upper management?

If it is an internal application, as indicated, then no, one doesn't have the same kind of sales context that one does buying a new application from outside where, among other things, one is looking at multiple competitors. For internal apps, "just like everything else we have now" is a frequent standard.

I am sure half of the Wall street companies will be very interested in this conclusion

You mean the ones whose mission critical applications are mainframe COBOL?

 

[rusguy]

Complaining that Progress doesn't support .NET very well, for instance, is silly if you are using V9 as a yard-stick.

I am sorry, I am not complaining, I am just saying that there is no point to choose Progress for a development of a new application. And when developing a new application one would probably choose the latest version of the language, so the question of the current version used it irrelevant

Usually you need to sell business value to upper management.

Don’t you need to sell a new technology with all its licensing costs to your management? If the company doesn’t have any investment in Progress and is a MS shop (or Java or anything else) it is going to be very hard to convince them to spend any extra money without selling that technology. And yes, people look at the look and feel, more than you think.

But it doesn't require multi-threading to do so and you definitely don't need to use a timer just to refresh a screen.

Well, if you have a browse that displays something in real time you do need to refresh it. And in order to do it without blocking a user input you do need to span it in a new thread. In fact, anything that takes some time to accomplish requires another thread. We are in the Progress world are not used to it, but people use it a lot, believe it or not.

Have you actually tried working with the Progress .NET GUI?

Unfortunately no real life experience yet (well, like most of the people right now), just tried/trying to learn it myself. Can’t see much work with it in a near future anyway.

As for the quality of the .NET documentation it is horrible. It is filled with circular references, incomplete explanations, half witted examples and utterly pointless drivel. And then when you Google stuff 99% of the results are crap

I am really surprised with your opinion, and I have no idea why I am not having the same problem with it. Probably the same reason why you insist on saying that Progress is the best thing on earth – you just got used to it. Also, I was so happy to work with MSDN after working for so long with Progress docs, that I really didn’t notice that something is so horrible in there.

Progress code is simple, clean and english-like

Yeah, it is very english-like, especially when there is a call to a web service, or working with sockets, or parsing xml, or pretty much doing anything except for each/display. And what is so non-english like in a sample from c#? If you don’t like the brackets use vb.net (just remove the brackets) and the syntax would be almost the same as in progress J

4GL uses more english-like constructs

It is true, but that is exactly what I meant a couple of posts back – Progress used to be such a language, not anymore. We are not in a 4GL only mode, we have plenty of non-English-like constructs in the language.

We're talking about business applications

So, what is so much easier to accomplish in a business application in Progress versus c# or vb.net with SQL?

 

[rusguy]

Because it speaks to the experience base from which you are speaking.

All current here, no worries

In particular, working with customer code architected in the 80s

I am trying to stay away from those if I can

just like everything else we have now

Exactly, and everything else in the company is not Progress – now you need to be a good salesperson to get Progress in. But I don’t see a reason to fight for Progress – that is where this discussion has started

You mean the ones whose mission critical applications are mainframe COBOL?

J No, the other half

 

[TomBascom]

Are we having fun yet?

 

[TomBascom]

I'm well aware that people are easily swayed by the look and feel. That's probably the only reason that I think that .NET is of any use. It does look good.

You're wrong about needing another thread to show a browser refreshing. Sure, it's one way to do it and yes, I would probably prefer to do it that way but it isn't the only way to do it and it certainly doesn't cripple an application to do it some other way nor does it make any of the UI controls unusable if you don't do it that way.

As for the documentation I guess we just have different perspectives. I also used to like the VAX/VMS documentation back in the day. The UNIX documentation is hideous by comparision. But it still kicks .NET's butt.

 

[TomBascom]

There are many considerations associated with any business application. Some are obvious and easy to explain. Like license costs. Others are indirect and difficult to account for. Like the costs of lost opportunities when you cannot change quickly enough.

Different people are going to approach these things differently. For some situations Progress makes sense. For others it doesn't. I'm not claiming that Progress is always the best solution nor am I claiming that Progress is not worth considering. And, even though it is tempting, I am not saying that C# et al are never appropriate.

 

[rusguy]

Are we having fun yet?

Indeed we are J

That's probably the only reason that I think that .NET is of any use. It does look good.

This is going to be harder than I thought J I am wondering if it would be easier for you to agree with me if .Net came from someone else other than MS J

it isn't the only way to do it

Of course it isn’t, especially if you just can’t start a background thread.

nor does it make any of the UI controls unusable if you don't do it that way.

Of course not, but the app just works “a little” different. We are so used to some workarounds while doing something in Progress. Multithreading in UI is used in .net and Java for a long time already, and we are still at level zero with Progress.

As for the documentation I guess we just have different perspectives

It seems to me that we have different perspectives not only in documentation J

But it still kicks .NET's butt.

Well, I am long time Unix hater just because of documentation J

Like the costs of lost opportunities when you cannot change quickly enough.

Are you saying that changing a stored procedure on a fly is harder than changing a .p, recompile and push it to all the gui clients?

For some situations Progress makes sense.

100% agree - if the company already has investment in Progress it does make sense to still use it.

For others it doesn't

Exactly, for anyone else outside of existing Progress customer base

And, even though it is tempting, I am not saying that C# et al are never appropriate.

This is a start J

 

[TomBascom]

.NET's MS pedigree isn't relevant. I couldn't care less. It's pretty, which is nice, but to me that is a distinctly secondary consideration. Making pretty things isn't the goal. Making money is the goal.

Like the costs of lost opportunities when you cannot change quickly enough.

Are you saying that changing a stored procedure on a fly is harder than changing a .p, recompile and push it to all the gui clients?

No, that isn't what I'm saying (nor am I saying that it is not).

That's another example though -- making changes too quickly has costs too.

Making a change in the wrong place has costs too.

 

[TomBascom]

Your position that nobody who doesn't already own Progress has a reason to consider Progress is ridiculous.

If you would like to discuss actual pros and cons of actual technical features (or lack thereof) that's ok and might even be fun but it is pointless to continue if you are just going to come back to that tired old assertion over and over.

 

[rusguy]

Making money is the goal

Yeap, that’s why I am still with Progress – it does pay the bills, not as much as before though

making changes too quickly has costs too

Making a change in the wrong place has costs too.

Isn’t it true for all technologies?

Your position that nobody who doesn't already own Progress has a reason to consider Progress is ridiculous.

That’s pretty much the reality of what is going on. Do you know of many new shops (with no experience with Progress) in early development stages that adapted Progress as their main development tool?

If you would like to discuss actual pros and cons of actual technical features (or lack thereof)

Yes, I do want to discuss that and I thought this is what we are doing here.

It is pointless to continue if you are just going to come back to that tired old assertion over and over

I am not sure I understand your point here? I am yet to hear a valid point that shows the advantage of adapting Progress as the main tool to build a modern app for a company that never heard of Progress before.

 

[TomBascom]

Yes, of course it is true for all technologies. But different technologies in different hands in different situations all have different weights. There is no one size fits all solution and that includes .NET.

As for not hearing any "valid" reasons I suppose you must have earplugs in place.

There are indeed new companies adopting Progress. Both new APs and new direct customers. You may be offended by that or you may not feel that the numbers meet your standards but it is true. People who have never used it before do in fact make the decision to go with Progress.

 

[rusguy]

But different technologies in different hands in different situations all have different weights

In different hands – this is the key word I was looking for. There are way more “different hands” in .Net/SQL world than in Progress, so when you do have a problem with something then it is so much easier to find someone to help you to resolve it. And I am not talking about cheaper or not – just to find the right specialist.

There is no one size fits all solution

Of course not, but with technologies in the subject line, one just fits more than the other, and in my opinion it is not Progress.

As for not hearing any "valid" reasons I suppose you must have earplugs in place.

Earplugs or not, but I didn’t hear any facts, you just saying that nobody uses .Net/SQL for mission critical systems – where did you get that from? Lets just look at any job board and see the names of companies that looking to hire people for .net/sql – are they looking for someone to work on a non mission critical system? What else was there that I had to hear? For each is better than foreach in another language? Disappearing english-like syntax in the language? No documentation? Or may be not enough books on a bookstand? The only valid point was that you do like the language, but it is not something that would help you to get the management to buy it. I do like the language as well, but I have an open mind to agree that there are other technologies that get the job done better.

People who have never used it before do in fact make the decision to go with Progress.

Wow, nice to hear about it, too bad they don’t talk about it more loudly – may be because it is not something they are proud of? Or did I miss some other forum where it is discussed?


Like any other religion topics, this discussion is turning to a stall - it is just hard to discuss something when some people are so easily offended by different thoughts on the same subject

 

[FrancoisL]

I am surprised that no one talked about Progress software horrendous and mysterious licensing model. :lol: I want to punch the progress sales rep every time i see him.

It funny how i can easily find cost sheets for Oracle or MS SQL but it nearly impossible to find pricing for progress except by talking to a sales rep .

 

[TomBascom]

In different hands – this is the key word I was looking for. There are way more “different hands” in .Net/SQL world than in Progress, so when you do have a problem with something then it is so much easier to find someone to help you to resolve it. And I am not talking about cheaper or not – just to find the right specialist.

More does not always equal better. Or easier.

.... with technologies in the subject line, one just fits more than the other, and in my opinion it is not Progress.

I think that your focus is almost certainly on small departmental applications. That is a problem space for which MS' tools are very well suited. For 25 years we've been hearing how those tools are going to make everything else pointlessly obsolete. It still hasn't happened.

Earplugs or not, but I didn’t hear any facts

I think you might want to carefully re-read.

... you just saying that nobody uses .Net/SQL for mission critical systems

What I actually said was:

rusguy:
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.

me:
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.

1) Mission critical applications aren't built by departmental teams.
2) Using C# and SQL Server.

They are built by either much smaller or much larger teams and (these days) using a much wider suite of tools and techniques.

– where did you get that from?

Experience and observation. Quite a lot of it from inside some of those big name companies.

Lets just look at any job board and see the names of companies that looking to hire people for .net/sql – are they looking for someone to work on a non mission critical system?

Look at the detailed job descriptions. Or the pay being offered. Most, if not all, of those jobs are for code monkeys slapping together toy applications or customizing canned applications. Just because a company has a big name doesn't mean that everything they are working on is "mission critical".

I've said over and over that different tools are appropriate for different situations. Where we differ is that I see a role for Progress and I see many positive characteristics about Progress that apply to more than just existing customers. I see lots of negatives too, just ask anyone in Bedford

 

[TomBascom]

I am surprised that no one talked about Progress software horrendous and mysterious licensing model. :lol: I want to punch the progress sales rep every time i see him.

A common feeling! Although hardly limited to Progress sales people

It funny how i can easily find cost sheets for Oracle or MS SQL but it nearly impossible to find pricing for progress except by talking to a sales rep.

Nothing pisses them off more than documented proof that their products are more expensive than the other guys. Don't forget that Oracle gives a 20% discount for being able to fog a mirror, a 30% discount for having a pulse and 50% for a purchase order.

 

[rusguy]

More does not always equal better.

But it sure makes it easier to find someone who knows what they are doing

I think that your focus is almost certainly on small departmental applications

Small and medium – exactly what original poster was asking about

For 25 years we've been hearing how those tools are going to make everything else pointlessly obsolete.

Did Progress change in last 25 years? Why do you think that SQL didn’t change much? Do you think that MS has less resources or less expertise to make something good out of product?

1) Mission critical applications aren't built by departmental teams.

2) Using C# and SQL Server.

I guess mentioning MS Dynamics here is wrong. So, lets see some other examples – SAP offers SQL on a back end, Yardi (.net web based solution) has pretty big clients that manage multi billion portfolios. And the list can go on and on. About the size of database – just google for very large database in SQL and you will see that there are some 400-500gb databases used by other people. Progress does have some more-than-terabyte-in-size customers but the number of such customers is very low (I think you did research about it a while back). But then again, we did talk about small/medium size companies and solutions at the beginning.

They are built by either much smaller or much larger teams and (these days) using a much wider suite of tools and techniques.

But while doing something bigger in Progress you must use other tools (Java for example), but when doing the same using MS tools you most likely wont need anything else.

Experience and observation. Quite a lot of it from inside some of those big name companies.

Once again we have different experience and observations here – most of the companies I talked/worked with that use MS tools on a daily basis are quite happy with them.

Or the pay being offered

Pay offered is quite the same in both worlds, but then again, amount of jobs and specialists is not the same.

Most, if not all, of those jobs are for code monkeys slapping together toy applications or customizing canned applications

And what about Progress jobs (or a lack of)? Aren’t most of the jobs available from companies that look for someone to customize/write reports against mfg/pro or some other big product?

doesn't mean that everything they are working on is "mission critical".

And everything we, progress programmers, do is mission critical? How nice!

Where we differ is that I see a role for Progress and I see many positive characteristics about Progress that apply to more than just existing customers

Again, except of accusations of others being “toy” tools I didn’t hear anything worth considering in terms of why one would choose Progress over any other big name technology.

 

[TomBascom]

Having a large pool of candidates only makes it easy to quickly obtain a warm body. It says nothing about the quality of the pool or the likelihood of obtaining a competent programmer.

Our original poster (who has probably fled in terror from this thread) has some experience with Progress. He expressed a desire to use it for his database because he likes many aspects of the database. He has the discretion to possibly use Progress for the entire project (regardless of size) if he feels that it is appropriate. Many factors which neither of us are privy to might come into that decision. He did ask for pros and cons. Among the "pros" which I have listed for Progress:

1. Progress is a mature and robust environment used by a great many companies around the world.
2. A unified front to back stack of technologies from a single vendor.
3. Having experience with Progress may mean that he also has existing relationships with Progress developers.
4. The Progress .NET GUI provides the look and feel that he seems to desire.
5. The Progress 4GL is a very "natural" language to code in which makes it very productive and suitable for business applications.

There are, of course, lots of other good reasons to use Progress.

If you review the thread you will also see a number of testable factual statements about the product's capabilities which refute many of your claims regarding the lack of those capabilities.

I've also spent quite a lot of effort debunking your opinion that only Microsoft .NET products should ever be considered for any project whatsoever.

This has obviously become a religious issue and we're just repeating ourselves so I suppose that it is time to stop.

 

[rusguy]

Having a large pool of candidates only makes it easy to quickly obtain a warm body

So the smaller pool is better, right? J

He did ask for pros and cons

He expressed desire to get pros for Progress in order to present it to his management so they will buy into it – this is just a very unreal job.

1. Progress is a mature and robust environment used by a great many companies around the world.
2. A unified front to back stack of technologies from a single vendor.
3. Having experience with Progress may mean that he also has existing relationships with Progress developers.
4. The Progress .NET GUI provides the look and feel that he seems to desire.
5. The Progress 4GL is a very "natural" language to code in which makes it very productive and suitable for business applications.

1, 2 and 5 applies to .net/sql. 3 is just his personal preference and doesn’t justify extra money spent, 4 is a must for any technology nowadays.

There are, of course, lots of other good reasons to use Progress

Like? Well, the question really was “why choose Progress”, not “why use Progress”.

If you review the thread you will also see a number of testable factual statements about the product's capabilities which refute many of your claims regarding the lack of those capabilities

There are indeed good things that Progress is capable of, no questions about it. But almost all of them do exist in other technologies and again, it doesn’t really justify choosing Progress for a shop that didn’t hear about Progress before.

I've also spent quite a lot of effort debunking your opinion that only Microsoft .NET products should ever be considered for any project whatsoever

Not only .Net, but any one from the list of current big name technologies. It just happens to be that I am doing more MS work than anything else these days and that’s why I can talk more about MS world than lets say Java.

This has obviously become a religious issue and we're just repeating ourselves so I suppose that it is time to stop.

Agree, let’s stop, this won’t change a thing in our minds anyway.