Re: new here, my lang project...

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/12/05 

Date: Wed, 12 Jan 2005 18:33:41 GMT

Responding to Cr88192...

> my oppinions are that:
> fp is suited for the small scale, eg, things internal to functions and
> performing tasks;
> procedural is good for intermediate level stuff, eg, stuff consisting of
> interaction between code and doing stuff too big for a single function;
> oo is better suited for the large scale, eg, more as an organizational
> feature imo.

I don't think FP is limited by scale. Hierarchical dependencies only
become a problem when (a) higher level functions are reused in different
contexts, which turns the decomposition tree into a lattice, and (b)
when the requirements are highly volatile. One tends to see (a) in
larger applications but if the requirements are stable, it doesn't
matter. In addition, FPLs provide alternatives to hierarchical
dependencies, such as function parameterization and explicit
modularization support. So I don't see any systemic bars to building
large applications via FP.

> imo, having all of them makes sense, one can choose the style that makes
> sense for an issue, or mix styles (eg: this has been used a lot, though my
> current "natural" style is more leaning in the direction of largely
> procedural with oo and fp bits stuck on...).

The problem is that if the 'issues' are small scale (i.e., at the class
or function level), then they tend to be interrelated. A&D
methodological approaches are designed to optimize for their goals
broadly across many such issues in the application. While a different
approach might be appropriate between applications or even between
subsystems, I don't think mix & match works well at a finer scale.

>>BTW, I suspect one of the reasons that you have difficulty "getting it" is
>>that you came to OO development via the OOPLs -- essentially from the
>>ground up. Unfortunately that path is strong on OOP but rather light on
>>OOA/D. Much of the stuff I have been talking about in this thread is
>>related to OOA/D rather than OOP. Because OO development isn't all that
>>intuitive, one needs a good basis in OOA/D even if one doesn't draw a lot
>>of bubbles & arrows during development. It is OOA/D that defines the
>>methodology of OO software construction.
>>
>
> I have no idea really what "ooa/d" is.

Therein lies the problem. B-) My assertion is that one cannot make
intelligent choices about mixing & matching specific features across
paradigms until one thoroughly understands /both/ the paradigms. For OO
development the core paradigm resides in the techniques for doing
analysis and design (OOA & OOD).

>
> people still actually use flow charts?...

I suppose. For OOA/D the notations tend to be graphical and they are
thinly guised enhancements of existing diagrams from the Structured
Programming era. That's because the underlying mathematics of the
computing space is the same and the notations are based on that mathematics.

However, you don't need to draw bubble & arrows to do OOA/D. What
counts are the underlying principles for construction. OTOH, the
graphical notations are convenient for /explaining/ OOA/D, so all the
OOA/D books use them.

>>>sometimes the pieces interact badly, and I change some things. I had this
>>>experience in my last lang, a lot of stuff didn't mix that well, and I
>>>learned from a few major problems I guess.
>>>this time I made many often subtle changes to try to avoid some of the
>>>problems.
>>
>>Trial & error is a tough learning curve. That's why there are OOA/D
>>methodologies -- to benefit from everyone's prior experience.
>>
>
> I still have not heard of them...
>
> avoiding trial and error is partly why I go and talk about stuff. the more I
> know up front, the less trial and error is needed.

And one good way of avoiding trial and error entirely is to embrace a
recognized development approach where other people have already worked
out the kinks. As far as specific OOA/D methodologies are concerned,
take a look at my blog under the Books category for some
recommendations. (Methodologies tend to correlate 1:1 with authors.)

>>>I personally dislike trying to be forced into a particular style, or
>>>being expected not to abuse the language in one way or another.
>>
>>My gut reaction here is: get over it. B-) If software development is
>>ever to become a valid engineering field, most developers will have to
>>have a whole lot more discipline in how they do software. [Note that
>>disciplined development is orthogonal to being creative. Discipline in
>>software development is about consistency in the way one is creative. The
>>rigor of good A&D methodologies is designed support the inherent
>>creativity of good designs.]
>>
>
> engineering field?!...
>
> no, I doubt it. imo "engineering" is antithetical to the coding experience.
> code is not constrained in the same ways as mechanical objects, and has a
> different set of problems and abilities, so I doubt traditional
> "engineering" practices are that relevant.

When I was growing up everything in one's life was breaking. A car had
a monthly flat tire and it usually spent a week in a repair shop every
few months. Radios, washing machines, toasters -- you name it and it
broke with regularity.

However, today the only thing that keeps breaking in our lives is
software. Consumers are beginning to figure that out. They don't care
about the developer's viewpoint; they just want the software to stop
breaking. Over the next decade that pressure is going to have a
profound affect on the way software is developed. The emphasis on
software quality will become a competitive business advantage for the
people signing the developer's checks. The only way that software
quality is going to improve is by making software development an
engineering discipline rather than an exercise in alchemy.

[Back in the late '70s I took a job in the electronic test industry
working for a marketing department. My job was to develop a set of
computer models that would use the customer's own data to prove that our
tester would find more faults than Brand G's tester. That was important
because our new tester cost 2X more (about $1m) than the competition's.
  That sales approach was very successful and eventually we ended up
buying Brand G.

However, by the mid-'90s that sales approach would have gotten the sales
guy thrown out the window. By that time industry in the West had gotten
the crap kicked out of it by the PacRim on the basis of product quality.
  Entire industries moved offshore as a result. The survivors learned
the hard way the one cannot test in quality; it has to be designed in.
That fundamentally changed the way testers were used in the electronics
industry; today they simply monitor processes that are designed to
prevent defects in the first place. That same sort of sea change in the
way products are developed is now facing the software industry.]

>
>
>>This is especially true in OO development. The differences between OOA/D
>>methodologies are rather minor compared to the difference between
>>employing any methodology consistently and not using a methodology.
>>
>
> I am not sure I get this.

There are lots of formal OO methodologies around: Booch, OMT (Rumbaugh),
OOSE (Jacobson), eUML (Mellor), etc. Pick up an OOA/D book and the
author is espousing a particular methodology for constructing OO
software. The differences between those approaches are significant and
each author will have no trouble giving you twenty minutes on why theirs
is the best one.

However, those differences pale in comparison to not using a particular
methodology consistently (i.e., compared to ad hoc development). If I
am wandering around in the dark, I might prefer a miner's lamp to a hand
flashlight or not. OTOH, that difference is trivial compared to
wandering around burning my fingers with just a pack of matches.

>>>even at the basic level, even often my use of while loops can be
>>>considered abuse, a kind of rebuttle for people having such gripes about
>>>goto. well, I have goto as well...
>>
>>After a couple of decades using gotos in PLI/I, COBOL, FORTRAN, and C, I
>>spent the better part of a decade programming in BLISS, which had no goto.
>>Once I learned the basic idioms to work around the lack, I never missed it
>>and I still don't. As a bonus, the software tended to actually be more
>>elegant from a design viewpoint without the goto.
>>
>
> well, in my experience, I almost never need goto, but I do so often at the
> cost of abuse to the while loop.
>
> maybe at least an abused while loop is a little more readable than labels
> and goto's at least, but does cost in an indentation level.

Amusing, if apocryphal, anecdote. A couple of decades ago a well-known
guru had a column in Computer Language magazine. One day he defended
the use of gotos. He used a code fragment to illustrate 'elegant use'
that was one of the most obtuse pieces of purported legitimate code I've
seen In about 15 lines he had maybe 12 gotos. It also had a least two
errors in it, as I recall. Evidently he got so much mail that he felt
bound to defend it with a whole column. AFAIK, he never included a line
of code in a column again for the next couple of decades that he wrote
columns for various magazines.

>>I think language development is nontrivial. There have been literally
>>thousands of 3GLs developed but very few achieved wide acceptance even
>>temporarily. Meanwhile languages like COBOL that everyone loves to hate
>>go on forever. Languages like C++ that technically awful survive while
>>many of the technically elegant academic languages never got serious
>>consideration outside of the universities.
>>
>
> maybe. academic languages can sometimes have interesting points, but often
> serious flaws that prevent them from really being used imo.

Right. Nocolas Wirth hated underscores for some reason. In Modula he
did not even include them as valid characters in the syntax. Basically
he ignored the controlled studies that indicated that reading
comprehension was reduced and eye strain was increased when reading
mixed-case identifiers compared to reading identifiers with underscores.
  That probably contributed to the failure of Modula at that time.
[Ironically, with the introduction of C the use of mixed-case
identifiers became de facto standard -- another contribution of the AT&T
School of Programming in the mid-'70s. Another contribution was, "If it
ain't broke, don't fix it", which set back refactoring by a decade or so.]

>>To be successful a language needs to balance what the developer wants to
>>do vs. what the developer should do. The first is aimed at what will best
>>allow the developer to achieve personal goals (e.g., enjoy using the
>>language) and professional goals (e.g., correctly solve the problem
>>easily) in the short term. The second is aimed at long-term business
>>goals like speed of development, maintainability, reliability,
>>performance, meeting customer requirements, etc. IOW, the second is about
>>producing high quality software by eliminating ways for the developer to
>>engage in foot-shooting.
>>
>
> err, why would developers really want to use a language that doesn't do what
> they want to do?...
> the only real reason I can imagine is that it is being forced on them, and
> not that it is their choice. that experience probably sucks.

Developers want convenience; they want to easy way to do things in
/every/ situation. That leads to all sorts of problems in languages
that allow the developer to take short cuts -- like routinely using
downcasts in C++ -- in lieu of taking the time to think about the
problem. Good developers look past that and seek languages that enforce
good practices so that they don't inadvertently shoot themselves in the
foot. They are willing to sacrifice some extra keystrokes and thought
to avoid the problems that lurk behind the Easy Way.

>
> now, I am neither academic nor commercial, I am hobbyist.
> I stumble around for what it is worth, eventually being faced with the
> problem that eventually I have to do something (eg: a job or whatever).
>
> I age, and as I do everything I do seems less impressive. in elem, and even
> highschool I was sort of respected, at least because I was achieving stuff
> for my age.
>
> now, I have since graduated highschool, and over time any respect just seems
> to have petered out (mind you, the school experience itself sucked hard, but
> I managed to graduate in the 4 years, barely...). I am now 21 with little to
> show for it (nor even a complete year of college, no, one semester is not
> exactly that cool sounding...).
> should be starting again soon, at least for another semester probably. a
> year has gone by since the last one, with my parents waiting for
> "non-resident" tuition rates to go away.
>
> I am a looser probably, why should what I do matter at all?...

Trite as it might sound, I would argue it matters because if one is
going to do something, one should try to do it right. A guy who builds
furniture as a hobby isn't a Carpenter and probably hasn't that level of
skill and experience. But the hobbyist should still strive towards
professionalism and do each piece better than the last.

[BTW, software development is a field with a whole lot of ego. In
nearly a half century in this business I have never met a professional
software developer who did not think that they were at least a bit
better than the average. The duds all seem to be the people who moved
on to a new job and left their code behind. So I'll appeal to your ego:
it does matter because you need to learn enough so that you can be
confident you are better than the average.]

> my goal was more to talk about language design than to flog off my lang, and
> comp.lang.misc has been a little flat recently...
>
> of course, I have damn near nothing worth saying either.

That goal is fine. As for the last, that's not true; otherwise I
wouldn't have wasted the time with this dialog. You represent a rather
large group of self-taught novices dipping their toes into software
development. (There tend to be a lot of lurkers on this forum and many
of them are in a similar position.) So your viewpoint provides a window
into the industry.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Loading