[Tfug] Language choices

[Bexley Hall]

Hi, T,

--- t takahashi <gambarimasu at gmail.com> wrote:

> at the low level, i'm not convinced that modern gc
> languages are quite as bad as you imply.  even if
> they are, there are subsets of at least one of those
> languages (scheme) that avoid gc.  you might want to
> check them out.

Would you write a web page cgi in scheme?  :>
Would you expect others to embrace that approach?
Etc.

> at the high level, i don't yet see the reason for
> inventing a new language or tweaking a language's
> syntax to a high degree.  note "yet": you probably
> have a reason, but you didn't state it.

Many languages have "features"/mechanisms that are
either clumsy, unnecessary or unwanted/troublesome.

E.g., you don't *need* a preincrement and
postincrement
operator in C.  Sure, it makes some expressions easier
to have each available.  But, you don't *need* both.

If you decide to keep programs small, you can do
away with external linkage (and, thus, the linkage
editor itself) and the syntax associated with it.

Features like REXX's string concatenation I consider
clumsy.  It *assumes* a space should be injected
between the concatenated strings -- *unless* you
invoke the operator using a slightly different
syntax that isn't readily apparent to a casual
reader (the "read it over the telephone" criterion).
I'd change the syntax (and semantics) so that the
user had to explicitly *add* any whitespace they
wanted to inject, etc.

Support for multidemnsion arrays may not be a
necessary capability.

"1 based" array subscripts could save a lot of
grief for developers (I'm tired of having to always
remember to offset indices by 1)

<shrug>  There are always little tweeks that can
make a language a bit friendlier (or, a bit easier
to implement).

> there are good reasons for doing that, but they are
> either very rare or they leverage existing languages
> by building on top.  the design effort of good
> language designers is something to take advantage
> of if you can, and sometimes represents decades of
> hard work.  some of your users might even speak the
> language already or wish to buy a book on
> it at a level at which you are loath to write.  is
> it possible that you are trying to take a shortcut
> through quicksand?

I find most languages are *not* well thought out.
Rather, they tend to be collections of ideas that
"seemed good" to someone at some time (e.g., read
Stroustrup's _The Design and Evolution of C++_ ;
look at the various C incarnations; look at how
perl has evolved over the years; look at how rigid
Ada is; etc.).

And, they are languages designed for general purpose
(or specific purposes).  So, they have to cater to
a variety of conflicting criteria.

OTOH, I can decide which features are important to
the types of applications that I need to address
and cull those that are superfluous.

E.g., I have a little language I wrote for building
state machines (finite automata).  It is totally
useless for use as a general Turing machine.  But,
blows the pants off all conventional languages
when it comes to coding FSMs!

> also a minor point.  you like recursion, but don't
> like functional languages.

*I* like recursion.  I don't think the folks who
will be *writing* these applets would, though!

> the two do not have to go together, but they often
> do. for example, scheme guarantees tail recursion 
> in the very standard.  this will ease your worries
> about blowing your stack.  however, you
> might want to load a standard loop macro for users.

Again, I think LISP dialects just wouldn't fly well.
Look at all of the folks out there who "build
web pages".  Using Flash, or perl scripts, or...
how many of those would embrace scheme?  Why
haven't they?  :-(

--don


 
____________________________________________________________________________________
We have the perfect Group for you. Check out the handy changes to Yahoo! Groups 
(http://groups.yahoo.com)