[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)



> -----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. 

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".

First, one can perform a significant body of useful programming without
ever using 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.

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").

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.

>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.
In fact, I am probably far more interested in being assured that the
person hired has the capacity to understand the problem domain first,
and has the skills to communicate, learn, and interact with other domain
experts involved in the project -- where the domain is not in and of
itself "computer-science". In the area of "computer language design",
the domain includes "computer-science", but that is not the case for
"all-software".

I.e., Business decisions about selection/hiring of a programmer are not
exclusively about a "best" skills and capabilities. There are cost
factors [over-qualification is not useful and is costly] and numerous
other tradeoffs. I'm sure you know this, but I still need to say it for
clarity. Business success turns on many factors. Software is
"engineered" in business. 

For selection of a (general - non-architect) member/employee/consultant
to be involved in a software project:  people [team] skills, management
skills, discipline/organization skills, and skill and experience with
the specific technologies being employed for creating "a"
stable/deployable/maintainable solution are more important than ability
to design "the" right solution.

When it comes to the business of design and implementation of the
"building blocks" of software and hardware systems, a formal scientific
and engineering foundation "is" pretty much essential. But it is not
necessary to have a formal foundation for one to "use" those
building-blocks/components to create software solutions.

[Note: I classify computer languages as one of the essential "building
blocks" of software].

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). 

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.

-- Dave S. [www.smallscript.org]