Re: 5th anniversary of 3.4.3, ideas

Janis Papanagnou <janis_papanagnou@xxxxxxxxxxx> wrote in
news:gigig5$hsb$1@xxxxxxxxxxxxxxxxx:

APLer wrote:

Yes if you go the OO design route, that is what is done. Whereas if you
stick with structured design you get similar results. I doubt the code
could be shortened much in any case.

I promise you that the source code size as a whole will grow, but
not much. Though the calls get much simpler and less error prone.
Object classes have well defined interfaces, and you don't suffer
from global side effects.

You can do a better code design as well in C, but C does not hide
all the details from you, thus leading to unnecessarily complex
code, thus making it more susceptible to errors.

Pure guesswork, but it has been
played around with for quite a while. Besides code size doesn't
necessarily mean it will run any faster or be less buggy.

With reduced wild dependencies you have the better chance to get
less buggy code that with the grown spaghetti code. (You can do
that to a certain degree in C as well, but then, why not take the
full move instead of tikering?)

Development and
changes in OO could easily take much longer as well.

Could, but in mid and long term would not. (I have just 25 years
of OO experience to back up my statement, unfortunately. No link
or other source at hand, sorry.)

It's a change without
a real reason other than style.

It's a lot more than that, and reading what you wrote I can just
speculate that you have no significant experience on the OO topic.

What exactly do you conside "no significant"? Would 2 years of Smalltalk
(and then C++ - although I've since completely forgotten it - happens with
things I dispise; I don't recall much Pl/I or COBOL either) at university
not meet your requirements? If so why not. What OO languages have you been
using at least 5 days a week for more than two years at a stretch?

Of course you can do everything in C as well, but that's not the
point. In C you would _see_ all the low level code that is hidden
in OO languages to provide the natural OO implementation. (Kent
mentioned examples.)

Where? certainly not after he said "for example" in his reply. Unless his
signature line is some form of abbreviation of one.

In summary, most of your observations of short-comings of using C seem to
fall into the catagory of not wanting to rely on the ability of the
programmer to code decently. Programming requires brains. Very few people
can do it well. Far more people think they know how to but don't come
close. The only problem is limiting the second category in their
"contributions" and getting enough of the first one would think.
.

Relevant Pages

  • Re: The Demise of C#
    ... design and reusability than a C++ programmer. ... There are syntactical conveniences (like the string concatenation operator) ... in both languages would be nice to have at once. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Laws of Intelligence -2
    ... > I was simply saying that raw materials are unintelligent. ... "design" of a wasps' nest. ... >>>animated characters in those films, and your programmer was ...
    (talk.origins)
  • Re: Another $17.4 Billion WASTED
    ... program from shrouded code is anything but "pathetically simple". ... perhaps with user-selected features and compiler ... uncommented code from a programmer that is using ... the detailed software design document put together by the PHD that ...
    (rec.autos.driving)
  • Re: Database access sucks!
    ... I do not answer questions on behalf of my employer. ... programmer helping programmers. ... > side cursors, when ADO was introduced the default was server side cursors. ... Other database access methods don't allow this goofy design, ...
    (microsoft.public.dotnet.general)
  • Re: lines of code?
    ... > goose wrote: ... >> is one that could benefit from a multithreaded design. ... against :-) java developers, ... The programmer has to figure it out ...
    (comp.lang.java.programmer)
Loading