List Processing Capabilities

[Alex Martelli]

<jerry_spicklemire at my-deja.com> wrote in message
news:8plo5h$u0m$1 at nnrp1.deja.com...
> In article <8pkoou0fle at news1.newsguy.com>,
>   "Alex Martelli" <aleaxit at yahoo.com> wrote:
>
> > Not to say you _can't_ do these things in Python -- you can, and
> > pretty well too.  But, there are even-better tools for them.  And,
> > no good craftsperson limits himself or herself to one single tool;
    [snip]
> Just to say that this sentiment is valid, and undeniable,
> but I'm stuck here in the "real world". It seems that many
> places employing programmers have an existing toolset and
> are "unsupportive" of the use of alternatives (or even the
> suggestion . . .).

Yep, that's true.  I work in the trenches, too, and while in
the long run I can influence the tools being used, in the
short run I must "live" within a given environment.  Still,
the environment may be larger than than one would think.


> The current designee appears to be Java, and so coders
> will be expected to deliver the universe according to Java,
> regardless of suitability.

Not at our shop -- C++ mostly reigns there (but with some
moderation: there's also a lot of scripting, albeit mostly
in our own proprietary language).  However, fitting some
Python there didn't prove very hard -- because Python is
so good at fitting into all sort of niches.

Similarly, I suspect, a sensible mostly-Java shop would
accept (for prototyping, scripting, etc) other languages
with a good solid implementation in JVM terms -- and
JPython fits that.


> As we all know, Python really is a language that can do
> many things very well, and has benefits such as simplicity
> and clarity, which leads to ease of learning & maintenance,
> and is available on many OS and hardware platforms. So,

True.  But it's also outstanding at integrating with _other_
software...

> it seems to me that in a world of defacto "winners", the
> first and most important job is to make sure that a
> language like that is adopted as the tool of choice.

But pushing it in areas for which it is sub-optimal may
not be the best way to ensure its acceptance elsewhere.

Whatever Java fans may think, I believe this is a
multi-language world, and becoming increasingly so.

Different languages are increasingly *easier* to use
together -- in separate cooperating components.  The
JVM enables that (to some extent) in the Java world,
COM and .NET enable that even more, and Corba is
also going in the direction of componentization.


> Otherwise we could easily find ourselves trying to code
> the next generation of software in a language left over
> from some hardware company's failed "set-top-box project.
> Or worse, some software company's counterattack strategy
> against the former!

Assuming the "counterattack strategy" you're thinking of is
MS's .NET, let me remind you that it is _intensely_ focused
on multi-language cohabitation and cooperation.  Python
will thrive in such a world, assuming Mr Hammond (and his
colleagues at ActiveState) do the outstanding job of it that
they are capable of doing -- but, also, many other more
specialized languages will, I predict, find a niche there, if
.NET succeeds.  Mercury, Haskell, Lisp-family languages,
will _all_ be available, *and able to interoperate better than
they ever could before*, with ALL system libraries equally
accessible.  You will, if you want, be able to implement some
classes in Mercury (to exploit its advanced mix of logical
and functional programming) and some in Haskell (for its
nonpareil elegance in FP), and inherit and extend from both
in Python, seamlessly.  Or, at least, that is the promise that
I see glittering before our eyes.

With inter-language "friction" well-nigh removed, shops
that are able to exploit the "best language for the job" at
each component's implementation should enjoy significant
competitive advantage over ones stuck in a one-size-fits-
all mentality.  Think of it as evolution in action...:-).

In the "ideal sw shop" I envisage, many, perhaps most of
the components would be in Python -- exploiting its many
areas of strength.  But the "knowledge-processing" ("AI")
engines would more likely be in Mercury (or ML, or...),
just as the "numerical computation" engines would be in
Fortran (or C, or...) -- think of NumPy, for example; would
you want to *implement* it in Python...?  *Using* it from
Python, now *that*'s the ticket...!-)


Alex