Language Niches (long)

[Robin Becker]

In article <mailman.996429234.13926.python-list at python.org>, Paul
Prescod <paulp at ActiveState.com> writes
>Robin Becker wrote:
>> 
>> ...
>> I believe that well designed languages define their own niche.
>
>I can give you many examples of beautiful languages that fell into
>disuse. Sather, Modula-X  and Objective-C jump to mind. The eternally
>minor languages like Common Lisp, Scheme, Eiffel and Smalltalk are also
>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?


>
> * C++ was promoted by Microsoft as the standard way to do GUIs on
>Windows

it still is, although it is/will now become .NET aware

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

>
> * Perl was the defacto way to do sysadmining when sed and awk ran out
>of steam

so C wasn't ever that needed?
 
>
> * Perl was also the defacto way to do CGI in the early web
>

I use sh, but who cares.


> * PHP hopped on the dynamic web content revolution after the "masses"
>decided CGI is too hard and too inefficient
>
> * 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. Visual basic is promoted by M$, Delphi is not and has as
many if not more adherents.


>
> * Ruby is the only scripting language that Japanese programmers can
>count on to have a strong Japanese community
>

The above is a list of languages; all are thriving. For some more nearly
dead languages try simula, simscript etc. What was that wonderful
rebarbative predecessor of m4 called?

You also leave out the true dinosaurs ie SQL, Cobol, Fortran, Algol and
similar. Wasn't there a wonderful language called PL/1?

There are also a whole load of special ones like troff/nroff/eqn/grap
etc etc.

All those macro languages for Word(perfect) Applix, Excel, Lotus are
also used quite a bit. Which are dead I have no idea.


>So that leaves Python ... the Zope scripting language? Not really ...
>Zope users do not dominate the Python community.



>I consider it an amazing achievement that Python is pulling itself out
>of obscurity purely on technical merit with no help from a growth
>platform like Unix or Linux or the Palm. Judging by history, that should
>be impossible. I think Python's only conceivable "niche" is
>cross-platform general-purpose rapid application development. Moore's
>law is slowly making type declarations irrelevant so there is a need for
>a language that allows coding faster than Java and yet can be used for
>the same big projects. Smalltalk has the taint of age and Ruby has the
>taint of youth.
>

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.

>Nevertheless, this is a somewhat precarious position to be in. Let's say
>that either of Ruby or Python were adopted as the "offical scripting
>language" for .NET or WAP or whatever the next dominant "platform" is.
>The boost given to that language might be enough to essentially wipe out
>the other one. "I have to learn language X to work with WAP anyhow. Why
>should I go to the extra effort to learn Y?" That's what happend to
>Objective-C (versus C++) and various text-hacking languages like Snobol
>versus Perl and various GUI environments versus Visual Basic etc.
>
>(note that I reject the polyanish notion that all languages can survive
>and thrive -- the closer two languages are in features, the more they
>are in competition)
>
>> ... A
>> language that constantly needs changing is clearly bad. 
>
>*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.


>Changing syntax all of the time is a sign of youth. It is also a sign
>that the user base is small enough and friendly enough to tolerate it.
>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? 

>> ... That's not to
>> say that programming languages shouldn't evolve. The Pascal family, the
>> B family each had something. Perhaps the Python family will develop,
>> perhaps not. Constant syntax change for a programming language is a sign
>> of weakness not strength.
>
>I would much rather see Python evolve than to see Python#, Jython,
>Python++ and various other variants split off while our community is
>still so small. But really, the int/int->float thing is not really a way
>of avoiding a fork. It is more a way of doing *the right thing*
>technically in the opinion of Guido and many others. The type/class
>stuff is more of a competitive advantage.

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