Language Niches (long)

[Bob Calco]

>>>I was demonstrating that the major languages that make up the
modern computing landscapes did so by grabbing on to a niche or a
particular task.<<<<

One language nobody's mentioned here (that fits into the point above, which
is why I thought of it) is Ada, which was created specifically for the DoD
in a competition (believe it or not) and is the only major language I know
of that has a complete, written rationale for every feature of the language
(or at least it was the first with such a rationale). It's a lot like Pascal
at first glance, so it isn't hard to read or learn. Problem with Ada now is
that the DoD dropped its long-standing "Ada-only" policy a couple years ago,
and it never has caught on as a desktop development language, for some
reason. Ada's got a relatively small but rabid following, and there are
ports of Ada on just about everything, especially various flavors of Unix
and Windows. Ada's got some pretty nifty constructs -- especially generics
and tasks -- that make it a great choice for real-time and distributed
systems development. In fact, chances are, if you've ever been on a
commercial airplane or a space shuttle or a long range bomber, your life has
depended upon Ada code. It's also got one of the most brutal compilers in
the industry -- it checks just about everything and your program won't in
most cases compile at all if anything (except perhaps for a business logic
error, which compilers don't look for anyway) is amiss. I have friends at a
company that makes Ada compilers and the outlook for Ada apparently isn't
bright. Its niche -- the DoD -- was just a little too well-defined, and even
though as a general purpose programming language it has some incredibly
we'll designed features that (would otherwise) easily place it among the top
choices for just about any problem domain, it too will enter the Smithsonian
of languages long before the seemingly immortal C. This is unfortunate
since, aside from unparallelled access to low-level bit-fiddling, which is
cool when that's what you need, C lacks support for a great many useful
semantic abstractions that make just about any other language more
appealing, at least to me. On the other hand, you can write a language with
all those useful semantic abstractions in C -- ergo, Python, Ruby, Perl....
so I guess it ain't so bad. :-)

BTW, some of the reasons I love (and hate) this mailing list is a.) the
sheer volume of python mail traffic crushes all competition among the lists
to which I subscribe, and b.) the propensity of its members to keep email
chains alive forever is almost pathological -- topics never go away, they
just keep coming and coming and coming ...back (particularly the
interminable "Which Language Is Best?" thread and of course the editor
wars). Of course the main reason I love it is Python itself, which (along
with stimulating computer language theory discussions that seem to accompany
it) is its own justification for sifting through the gobs of mail its users
generate daily.

Just-doing-my-part-to-keep-tradition-alive-ly yours,

Bob Calco

# -----Original Message-----
# From: python-list-admin at python.org
# [mailto:python-list-admin at python.org]On Behalf Of Paul Prescod
# Sent: Sunday, July 29, 2001 5:36 PM
# To: Robin Becker; python-list at python.org
# Subject: Re: Language Niches (long)
#
#
# Robin Becker wrote:
# >
# >....
# > >worth consideration.
# > >
# > >Now let's examine some of the other languages out there:
# > >
# > > * For a long time, C was the only way to do system
# programming for Unix
# >
# > what language does one use nowadays. If not C then pretty much any
# > scripting language can do the same things as C given that we have the
# > wrapping tools like swig. What's swig coded in?
#
# I'm not sure what point you are trying to make. C became popular between
# twenty and thirty years ago. Its current popularity is a result of that
# early boost. Python is not typically used for "systems programming." I
# think of systems programming as the programming that goes into building
# the heart of an operating system or relational database etc.
#
# >...
# > > * Java was the only way to do client-side graphics and then evolved
# > >into "Servlets" and "EJBs"
# >
# > Java actually represents a new thing; write once run anywhere.
#
# Java is not much better at that than Tcl or Python.
#
# > >
# > > * Perl was the defacto way to do sysadmining when sed and awk ran out
# > >of steam
# >
# > so C wasn't ever that needed?
#
# For system administration? I would say "not much". Systems programming
# and system administration are two different thing.
#
# >...
# > > * Visual Basic and Tcl were the only easy way to make GUIs for their
# > >respective platforms for a long time
# >
# > This is just nonsense. There are many ways to do CGI and even more ways
# > to do guis. You neglect all those other semi-proprietary languages. The
# > H***card one is an example. Even if you restrict Tcl to unix, Tcl is
# > only a scripting language. The Tk extension is what makes Tcl/Tk into a
# > gui platform.
#
# Right. And Tcl became popular while it was only possible to program Tk
# in that one language and it lost popularity when Tk became popular in
# Python, Perl etc. That goes to the heart of my argument. Tcl's
# popularity was a side effect of the popularity of its platform. Expect
# was another driver for Tcl's popularity.
#
# > ... Visual basic is promoted by M$, Delphi is not and has as
# > many if not more adherents.
#
# Delphi came years after Visual Basic. Really, if Microsoft did not
# invent Visual Basic as a GUI-building technology the Basic language
# would be long-since dead. In fact you could argue that it is because
# Visual Basic is becoming less and less Basic-like.
#
# >...
# > The above is a list of languages; all are thriving.
#
# Not all of them are thriving but all of them gained popularity based on
# a particular environment or niche programming task. Sometimes the
# environment got generalized (Tk and soon Visual Basic) and sometimes the
# language outgrew the environment (C). But not once did a language carve
# out its own niche based purely on technical merits (as you claim). If
# Python does so it will be the first.
#
# > ... For some more nearly
# > dead languages try simula, simscript etc. What was that wonderful
# > rebarbative predecessor of m4 called?
#
# I wasn't trying to be comprehensive. There are thousands of languages
# out there. I was demonstrating that the major languages that make up the
# modern computing landscapes did so by grabbing on to a niche or a
# particular task.
#
# >....
# > I consider the above to be an assertion. I certainly don't know the true
# > number of regular Python users now or in the past. Perhaps we could do
# > some comparative newsgroup posting analysis to get some idea of who's
# > programming/interested in what language. But all of the little languages
# > would be as noise to SQL and Cobol (even if you count them as languages)
# > in terms of the total code volume and economic significance.
#
# So your point is that SQL and Cobol carved out their large market shares
# by being technically wonderful and wonderfully stable? I find that
# extremely hard to believe. Look at the growth in the SQL standard. Look
# at the quality of the Cobol language.
#
# I'm waiting for you to point out a language that was so great
# technically that it became very popular without hooking on to some
# particular niche or platform or at least having a company with a
# billion-dollar valuation behind it. This is a real problem for Python.
# It has no big company and only tiny niches.
#
# > > ....
# > >*All* of the scripting languages change constantly. I guess
# they are all
# > >bad.
# > >
# >
# > in some senses yes.  A *good* programming language is one that is easily
# > applicable to a large set of problems. Sed is clearly not very good at
# > matrix algebra. Awk can't plot graphs. Sed is easily better than Python
# > at most simple stream substitutions. Python beats awk at list processing
# > etc etc etc.
#
# So SQL and COBOL are your examples of "good" programming languages?
# Because of their wide generality????
#
# >...
# > >There is a lot of crap in C and C++ that the inventors of those
# > >languages would like to change but it is too late now. Guido is trying
# > >to avoid that fate. As an aside, Perl users seem remarkably
# accepting of
# > >change considering the installed base of the language.
# > >
# >
# > So these languages aren't mature?
#
# No, compared to languages that are 20 or 30 or 40 years old, Perl and
# Python are certainly not mature. In particular, many people use Python
# today in radically different ways than they would have five years ago
# (in particular much bigger projects). They make certain demands on
# Python that may cause it to grow in particular directions. Five years
# from now there will be other new users with other new demands. I don't
# see that happening for C or COBOL or SQL.
#
# >...
# > If there were a single right way there wouldn't be so much discussion.
# > The one true way is often wrong, otherwise we wouldn't have seen the
# > Architect change the '/' operator.
#
# That's why I used the word "opinion".
#
# Every change is a question of costs and benefits. While the user
# community is small, the costs are smaller than they will be when the
# community is large. That's why Python changes so much more quickly than
# C or C++. It doesn't mean that it is worse, merely that we have more
# opportunity to improve it than those who are stuck with hundreds of
# millions of lines of legacy code. Guido is no more or less benevolent
# than those who do not have the option of fixing their languages. He has
# the opportunity, so he takes it. They don't.
#
# --
# Take a recipe. Leave a recipe.
# Python Cookbook!  http://www.ActiveState.com/pythoncookbook
#
# --
# http://mail.python.org/mailman/listinfo/python-list
#