[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)



"David Simmons" <David.Simmons@smallscript.net> writes:

> > -----Original Message-----
> > From: owner-ll1-discuss@ai.mit.edu
> [mailto:owner-ll1-discuss@ai.mit.edu]
> > On Behalf Of jmarshall@mak.com
> > Sent: Wednesday, December 19, 2001 8:35 AM
> > To: ll1-discuss@ai.mit.edu
> > Subject: Re: Functional Paradigm popularity and Maths (Was: XML as a
> > transition to s-expr)
> > 
> > 
> > >    Date: Wed, 19 Dec 2001 04:23:06 -0800
> > >    From: "David Simmons" <David.Simmons@smallscript.net>
> > >
> > >    Lisp requires one to think in terms of "lists" and "recursion".
> > 
> > Yes, but that is the nature of computer science.  Would you hire a
> > programmer unfamiliar with both recursion and lists?
> 
> I believe that you are following an erroneous line of reasoning. So I
> will now engage in a, brief, opinionated set of statements in what might
> seem to be academic heresy. 

Ok, but let me rebut.

> Your question requires a definition of "programmer", and a context in
> which that "programmer" is expected to achieve some "goal(s)" based on
> some "skill-set".

I think the standard definition of `someone who makes a living
programming computers' is adequate for this argument.

> First, one can perform a significant body of useful programming without
> ever using recursion. 

Well, this is debatable.  You can certainly write reams of code
without ever having a function explicitly call itself.  Whether such
code is `significant' or `useful' is a value judgement.  

However, if you look at it from a semantic point of view, having a
function explicitly call itself is simply one case of finding a
fixed-point.  Iteration constructs also find fixed points.  So if
you use any kind of iterative control structure, you are using
recursion whether you know it or not.  I have seen very little useful
code that uses neither iteration nor explicit recursion.

> Second, as to lists, thinking in terms of one-level deep lists
> (arrays, vectors, etc) is not the same thing as being
> fluent/comfortable/natural/intuitively being capable of thinking all
> the time about everything in terms of list forms.  And this
> one-level deep thinking is a far cry from fundamentally thinking
> about software programs in terms of s-expressions.

Granted.  And I would not consider someone who could only think in
terms of one-level-deep structures adequately trained.

> Third, you use the phrase "computer science".  But the relevant
> (business focus) hiring decisions center around "domain expertise",
> team skills and professional skills with best-practice techniques
> for "software engineering" (not what I believe you are terming as
> "computer science").

Sure, but wouldn't you expect a structural engineer to be somewhat
familiar with metalurgy?  They ought to know that concrete has no
tensile strength, and that steel rusts.  By analogy, I would expect a
`software engineer' to understand recursion and linked lists (in
addition to numerous other things).

> For an "architect", "project-designer", "team-lead" a formal
> foundation in "computer science" disciplines is of great intrinsic
> value.  But the fact that many successful products and technologies
> have been developed by people without such a foundation should make
> the point clear.  Many if not most advances in the commercial growth
> and evolution of the software industry were created by those
> "without" such a formal foundation.

I disagree with this.  Can you support this with hard data?

> From a business pragmatics point of view it is only essential that
> they have good (not even solid) foundation in the building-block
> aspects of the relevant technologies being utilized.  I would not
> hire PhD in English literature to be a receptionist at a company.  I
> would not hire an MD to perform the duties of a nurse.  I would not
> hire a master chef, to be a cook at McDonalds.
>
> So why should I "always" need to hire a person with a "solid/formal"
> foundation in computer science for working on a given software
> problem.

Because you would not hire a nurse whose only experience with medicine
is anecdotal.  Because you would not hire a cook that did not
understand that incorrectly prepared food can be fatal.

> Certainly, the vast majority of people who write software in one
> form or another do not have such a informal (let alone, formal)
> foundation.  They do, by and large, have some form of domain
> expertise which they are attempting to translate or express to a
> computer through the medium of a computer language (the
> man-machine-interface).

Yes, and the vast majority of software written by such people is
crap.

> Industry history illustrates that, (for better or worse) those
> without a "computer-science" foundation are [as a collective whole,
> probably more often than those with a "computer-science" foundation]
> able to successfully build and deploy commercial products and
> solutions.

It does?  Is this considering the entire track record of the industry?

There is a prevailing myth that untrained programmers are at least as
good if not better than programmers that have had years of training.
In my experience, this is simply false.