Re: Noun Oriented Thinking Considered Harmful


"Michael C." <Michael@xxxxxxxxxx> wrote in message
news:44d31f47$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Kristofer Skaug wrote:

I'm celebrating "Delphi Global Functions Appreciation Day!" (again!)


Yes.

I like Delphi because it doesn't force me to use classes or interfaces to
find solutions to problems.
I actually love the fact it gives
ME THE FREEDOM to decide what I WANT TO USE solve a problem.
I like being able to use pointers, classes, memory management, functions,
procedures, etc.
Hopefully, it will continue to stay this way.


I have only seen the last couple of posts in this thread that seems to be
debating the merits of hybrid procedural/object-oriented languages like
Object Pascal and entirely object-oriented languages like Java and C#. May I
add some further thoughts arising from my personal programming needs and
experience?



I am currently developing a large and complex engineering analysis
application, and usually start developing a new unit of functionality in an
object-oriented manner as a family of classes. This generally works
reasonably well for classes that implement data management, where
effectively the class is a stand-alone entity. Thus classes are fine to
implement collections, stacks, streams, databases, visual components etc..
They are also the best solution when polymorphism is required.



However I often find that when I have to program what may be most logically
and succinctly defined by a series of mathematical functions, where each
variable can be a function of any number of other variables, and the world
behaviour being modelled does not depend on a single class of object, but on
the interaction of several classes of object, I am forced to back-track and
recast the functionality as a series of global functions and procedures.
Suddenly code that was beginning to take on a convoluted logical structure
as difficult to readily comprehend as the deplored spaghetti code of old,
becomes simple and straightforward to understand, and more flexible to
reuse. If I may draw a parallel: to comprehend spaghetti code containing "go
to" jumps you needed a flowchart diagram to help you - you couldn't
understand the logic by just by reading the statements in a linear
sequential fashion. And today to comprehend some object-oriented code you
again need one or more diagrams - UML diagrams showing inheritance trees,
ownership structures, inherited properties, and the like. The structured
programming paradigm introduced in Pascal and perfected in languages like
Modula and Ada did away with the need for diagrams - you could understand a
well written procedure just by reading it line by line.



Moreover, to reuse procedures and functions by the class inheritance or
interface models is far more restrictive than by the global procedures
model. Common obstacles include the inability to use multiple inheritance,
the lack of differentiation between data references and owned data, lack of
information about inherited variables and behaviour, and the inheritance of
a lot of overhead that is not needed.



Another point is that in my field of scientific programming a procedure is
sometimes not just a few lines long - sometimes it needs to be say about a
page long. To have to intermingle this voluminous block of code in the class
definition makes the class definition truly unreadable, because you cannot
see the class definition in its entirety in say a single page. The
separation of interface and implementation parts that Delphi inherits from
Modula-2 is a language feature that I would find hard to do without.



A third point is that forcing certain types of problem to fit into the class
straightjacket is more bothersome that forcing them into the strongly typed
straightjacket of the original ISO Pascal used to be. It adds overhead to
the code and reduces simplicity - maximum simplicity being the goal that the
developer of reliable software should always aspire to.



To conclude may I add that it's sad to see bookshops treat Delphi as if it
were a legacy or specialist language like Fortran, rubbing shoulders with
Cobol. Delphi needed more promotion in academic and professional spheres,
and more books that explain its benefits over more fashionable current
languages, as well as entering into the minutiae of systems programming.




.

Relevant Pages

  • Re: The Lambda lambada...Why embedded SQL is becoming irrelevant and why you should start looking at
    ... Delphi Pascal -> around 2,000,000 hits ... least as good as other languages, and they support OO and Visual ... programming), but rather from the fact that Borland was unable to really ... released Vista is a quick rewrite based on 2003 kernal with some UI ...
    (comp.lang.cobol)
  • Re: Is delphi a good introduction to programming?
    ... > If you're completely new to programming, I'd avoid Delphi altogether ... > lovely IDE (in Delphi versions 2-7, ... > "scripting" languages, or a BASIC to get ... started off programming in assembler, moved to gw-basic for a while, found I ...
    (comp.lang.pascal.delphi.misc)
  • Branching Out / "Diverging" from Delphi
    ... programming languages to learn to help improve my career, ... Came to work with Delphi 5 for the past 6 years and it has been a wonderful ... I haven't had the need to work with any of these in my career, ... seem important for their variance in programming methods. ...
    (borland.public.delphi.non-technical)
  • Re: What is object oriented programming?
    ... Delphi nor TP would not be considered an fully OO ... Supporting inheritance is ... the most important attribute and allowing procedural programming and not ... "Object-based" means that one is otherwise OO except that inheritance is not ...
    (borland.public.delphi.non-technical)
  • Re: Wanting to Learn
    ... There are a lot of things to consider, specially the type of programming ... which is Delphi. ... writing with these kinds of languages and compilers, ... on _what_ you are solving rather than _how_ you are solving it. ...
    (comp.lang.c)