Procedural ["bare ASP.NET"] versus OOPy ASP.NET

[parley]

After several years of programming WWW applications in ASP.NET (and
several other frameworks) our division has come to what might seem a
counterintiutive conclusion:

Writing ASP.NET code in a "procedural" manner (without webcontrols and
without utilizing OOP concepts in general) produces code that is
remarkably faster and more scalable. In general a "bare ASP.NET"
application outruns it's OOPy counterpart by factors of 2 to 10.

Surprising side-effects are that the procedural version has reduced
memory requirements, is easier to maintain and it is easier to explain
and debug. While reusability was a goal in the OOPy versions, that
goal proved elusive, since a developer must be taught the intricacies
of any new reusable component he is given (he can't merely plug it
into an application without understanding it fully) and because, to
design a reusable component one must know beforehand all the ways it
will be used in the future, something that is difficult if not
impossible.

If our programmers _were_ inexperienced, I would chalk this up to
inexperience. But this is the conclusion of our programming group,
which has written software on many platforms using various languages
(OOP, procedural, and functional) over many years. While OOP certainly
has it's place (e.g., it is particularly useful in writing real-time
telecommunications software), that place does not seem to be WWW
applications. I might add that our developers are very familiar with
Internet standards and protocols, something that may not be true of
developers in general.

Our productivity on WWW apps has increased significantly since we
accepted this surprising conclusion. Have other shops concluded the
same? What are the experiences of other ASP.NET developers?

Bob

 

[Marina]

I won't comment on the speed, as I do not know. But I guess the overhead
involved with using a control, that's not just bare bones.

Now, by procedural code, do you mean Response.Write'ing everything out? If
so, I can't imagine anything that would make a web app more difficult to
maintain, extend or reuse, then that. Once the learning curve associated
with learning how to use the server side web controls is taken care of (and
by the way, this is not that huge a learning curve), development becomes
easier. Once reusable controls that include code, etc are created,
development becomes even faster. Yes, no one can know how to do it right
100% the first time - but every control gets refined and has new features
added over time.

 

[Kevin Spencer]

The clue as to your developer's conclusions can be found in your message:

inexperience. But this is the conclusion of our programming group,
which has written software on many platforms using various languages
(OOP, procedural, and functional) over many years. While OOP certainly

Probably too many years, and not willing to keep up.

Here's the thing. Take DOS for example. No doubt you can write a program for
DOS that runs much faster than one written for Windows XP. There's a heck of
a lot of overhead in creating a multitasking, multiuser, network Operating
System. But there are many good reasons why nobody uses DOS any more. There
are many good reasons for making ASP.net object-oriented. Too many, in fact,
to enumerate here. And sure, it's uncomfortable to keep up with the latest
programming technologies. But if you don't, you'll be out of business if a
few short years.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Michael Pearson]

Well, I know that I use some OOP features (inheritance) for my pages and I
know that makes things MUUUUCCCCHHH faster to develop and test. As far as
performance, I've not tested it both way so I can't say. My way seems
pretty darn fast as it is. Any performance loss that I'm taking I'm willing
to take so that it takes me just a few minutes to throw a new page together
and test it.

Michael

 

[Brian W]

Not to mention, the developers will quickly learn they are technologically
stagnant and falling rapidly behind the curve and will jump ship at the
first opportunity. Yes, even in this crappy economy, it just may take them a
little longer to find something new.

As word spreads, and it ** will ** spread like wildfire, it will become
ever-increasingly difficult to find quality developers/engineers that are
willing to work for such a company.

I've seen it happen, quite often. Hell, I've even been the "ship-jumper"
once or twice myself

My $.02


Brian W

 

[Michael Earls]

Why don't you guys try COBOL.NET?

I can't tell if this is serious or not, but It's not April 1st, so I assume
it is. Based on your statements, I'd recommend tossing ASP.NET completely
and using either ISAPI or implement your own handlers. I still can't figure
out how you've determined that it's easier to maintain, though. Also, you
ought to consider marketability of yuor skillset if/when something bad
happens to your current business.

I'd be willing to bet that given a few years of this behavior, you will have
reinvented just about every useful feature of the framework, and written
mounds of unmanagable "spaghetti-code".

Good luck.

Oh, to answer your "query", I'd have to say that you're the only "shop" that
I've heard of that has decided not to use OO with .NET.

Michael Earls
http://www.cerkit.com/

 

[parley]

Answers for those who responded:
To Marina's statement:
M> Now, by procedural code, do you mean
M> Response.Write'ing everything out?
Yes.
M> I can't imagine anything that would make
M> a web app more difficult to maintain,
M> extend or reuse, then that.
So we also thought it might be. But our experience did not confirm our
expectations.
That something like 99% of current successful web applications already
written were written in procedural form should have tipped us off that
a procedural methodology may be more natural to HTTP-based WWW
applications than is OOP. Only a fraction of such apps are written in
an OOP framework (e.g., Java, .NET) and of that the .NET fraction is
very small. But we ignored that fact when we began.

To Kevin's statement:
K> Probably too many years, and not willing to keep up.
Our division has deep experience in OOP and is very current!-)

to Brian W:
B> the developers will quickly learn they
B> are technologically stagnant and falling
B> rapidly behind the curve and will jump
B> ship at the first opportunity.
You misunderstand how our division came to these conclusions. These
conclusions were not forced on us: we discovered them. (read more
below)

to Michael Earls:
E> Based on your statements, I'd recommend
E> tossing ASP.NET completely
We decided that would be "throwing the baby out with the bath water":
there's much marketing advantage to running on the IIS platform under
..NET. But to continue the metaphor(perhaps poorly), we found that
Webcontrols and other more developed aspects of NET's OOP framework
were much like a Rubber Ducky: while pretty, they were unnecessary,
caused us to splash lots of water around and remain in the tub longer
than necessary.

E> I still can't figure out how you've
E> determined that it's easier to maintain,
E> though.
We tried it both ways over an extended period of time.

E> Also, you ought to consider
E> marketability of yuor skillset if/when
E> something bad happens to your current business.
There is no possibility of something bad happening to our current
business, but if our company went bankrupt tomorrow, each of our
developers would be eagerly snapped up by excellent companies.

The responses so far seem to be individual's gut reactions (which I
understand) to my initial post rather than the findings of groups who
have done experiments, as we have.

Surely there are other large groups out there who have benchmarked
ASP.NET WWW applications in various modes:
- cookieless execution
- JavaScript-less execution
- use of Response.Write
- webcontrols vs htmlcontrols
- overhead of various .NET objects and design patterns
- home-grown objects vs .NET's default objects
etc.

Scales of interest include performance, memory footprint, scalability,
cost and effort of initial development, cost and effort of
maintenance.

Please share your experiences.
Bob

 

[Brian W]

I stand by what I said.

I would be willing to bet there is more than one person in your shop that is
[at least] secretly saying, regardless of your, so called, "findings",
"this is f**king b**lls**t!" (unless it is a 1 or 2 person shop) Even if
they are content with it now, see what they are doing after a year or so.
For that matter, try to hire a qualified ASP.NET developer or 2 and see how
long they stay.

Perhaps if your findings are so "groundbreaking" you should publish. I
doubt you could back all your findings consistently.

IMO you will be hard-pressed to convince anyone that frequents this NG that
"your way" is better.

Please enlighten us, tell us what company this is so that we can all avoid
it.


Regards
Brian W



[snip]

 

[Kevin Spencer]

To Kevin's statement:

K> Probably too many years, and not willing to keep up.
Our division has deep experience in OOP and is very current!-)

If that was so, your group wouldn't be recommending a proprietary,
procedural, non-extensible approach. Best of luck to them.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[parley]

For people other than those who responded:

If you have nothing constructive to say, please keep your peace. We're
not in a religious dispute, but responses so far have been non-factual
and best described as "OOP zealotry" and with no reference to
experience.

To Kevin who posted:
K> If that was so, your group wouldn't be recommending
K> a proprietary, procedural, non-extensible approach.
K> Best of luck to them.

We keep libraries as portable as possible. We have thousands of
subroutines, macros and include files, thousands of objects in various
OOP languages and the ability to move code from one language to
another. Our solutions are non-proprietary.

As a result our code is _more_ extensible, not less. We use OOP where
it is useful and avoid it where it is a hindrance.

But as an aside, what could be more proprietary than writing code in
only C# or VB.NET?-))
You should broaden your perspective.

K> Kevin Spencer
K> Microsoft MVP

Oh, a Microsoft MVP!
At yesterday's meeting our managers had a laugh over this one: Kevin
gets a T-shirt for being a Microsoft attack dog, while our programmers
(and Microsoft's) get $200k and up salaries and stock options for
being real programmers (who use .NET, but not _only_ .NET):
"There's a sucker born every minute."
-P.T. Barnum

To Brian who stated:
B> I've seen it happen, quite often. Hell,
B> I've even been the "ship-jumper" once
B> or twice myself
and
B> "this is f**king b**lls**t!" (unless it is a 1 or 2 person shop)

We did some checking:
Being laid off because of personal attitudinal problems is not
"ship-jumping". And while there's nothing wrong with being bisexual,
Brian, it's best to keep that information private and out of the
workplace. Mostly its how a person handles his or her emotions. One
said that the herpes flareups seemed to cause anger, but there are
drugs available for that.

Bob

 

[Kevin Spencer]

To quote your message: "If you have nothing constructive to say, please keep
your peace." Insulting people who want to help you is far from constructive.
Hypocrisy is also far from constructive. Have a good laugh over that one.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Brian W]

Kevin --

Don't worry, I won't stoop to his level.

Just for fun, Kevin, Google the email address he used to post this message.

Here is an example of what comes up (one of only a very few):
http://www.dotnet247.com/247reference/msgs/38/193480.aspx

There is no evidence this person has even attempted to contribute anything,
useful or not.

Given that information I conclude that he has created this Yahoo! email
address so he can start holy wars and/or just to insult people.

Most of us "normal" people know, and respect, that it's not just anyone who
can become an MVP, and that you give of you time freely, as well as maintain
a real life and job.

Keep up the good work, Kevin!


Regards
Brian W

 

[Kevin Spencer]

Thank you Brian. You're very kind.

--
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[jim corey]

I thought your original post was reasonable enough, but it evidently
got some people upset.

I think maybe if you had stopped after the paragraph about the
performance and left it at that, then you might have gotten a response
on that point, which I was looking forward to.

I can imagine situations where one might want to back away from a
complex OOP architecture to get better performance, but I don't know
how much this is happening out there.

Jim