Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #479 > unrolled thread

Have we reached the asymptotic plateau of innovation in programming language design?

Back to article view | Back to comp.compilers

Contents

  Have we reached the asymptotic plateau of innovation in programming language design? Rui Maciel <rui.maciel@gmail.com> - 2012-03-07 13:52 +0000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-03-08 00:44 -0600
      Re: Have we reached the asymptotic plateau of innovation in programming language design? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-14 09:51 +0100
        Re: Have we reached the asymptotic plateau of innovation in programming language design? Gene Wirchenko <genew@ocis.net> - 2012-03-19 08:00 -0700
          Re: Have we reached the asymptotic plateau of innovation in programming language design? torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-21 11:53 +0100
            Re: Have we reached the asymptotic plateau of innovation in programming language design? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-03-22 21:17 +0100
            Re: Have we reached the asymptotic plateau of innovation in programming language design? jgk@panix.com (Joe keane) - 2012-03-23 19:45 +0000
      Re: Have we reached the asymptotic plateau of innovation in programming language design? eijkhout@tacc.utexas.edu (Victor Eijkhout) - 2012-03-19 15:42 -0600
        Re: HPC and parallel programming, was Have we reached the asymptotic Marco van de Voort <marcov@toad.stack.nl> - 2012-03-21 10:28 +0000
    Have we reached the asymptotic plateau of innovation in programming la SLK Systems <slkpg3@gmail.com> - 2012-03-08 10:21 -0500
      Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-09 18:16 -0700
        Re: Have we reached the asymptotic plateau of innovation in programming la glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-12 07:42 +0000
          Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-13 02:27 -0700
            Re: Have we reached the asymptotic plateau of innovation in programming la glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-03-14 05:19 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming la BGB <cr88192@hotmail.com> - 2012-03-15 00:06 -0700
            Re: Have we reached the asymptotic plateau of innovation in programming la torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-03-14 09:24 +0100
      Re: Have we reached the asymptotic plateau of innovation in programming languages? "robin" <robin51@dodo.com.au> - 2012-03-11 21:09 +1100
      Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-06 17:38 +0000
        Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-06 22:40 +0000
          Re: Have we reached the asymptotic plateau of innovation in programming languages Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-06-07 08:00 -0400
            Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-07 17:21 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-08 22:31 +0000
              Re: Have we reached the asymptotic plateau of innovation in programming languages Martin Ward <martin@gkc.org.uk> - 2012-06-10 10:42 +0100
              Re: Have we reached the asymptotic plateau of innovation in programming languages Alex McDonald <blog@rivadpm.com> - 2012-06-10 13:36 -0700
                Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-11 20:21 +1000
                Re: Have we reached the asymptotic plateau of innovation in programming languages Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-06-11 18:18 +0200
            Re: Have we reached the asymptotic plateau of innovation in programming languages Georg Bauhaus <rm.dash-bauhaus@futureapps.de> - 2012-06-08 16:16 +0200
        Re: Have we reached the asymptotic plateau of innovation in programming languages "BartC" <bc@freeuk.com> - 2012-06-07 14:20 +0100
          Re: Have we reached the asymptotic plateau of innovation in programming languages Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-06-07 16:06 -0400
            Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-08 22:47 +0000
        Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-08 00:03 +1000
          Re: Have we reached the asymptotic plateau of innovation in programming languages Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> - 2012-06-07 18:01 +0000
            Re: Have we reached the asymptotic plateau of innovation in programming languages Lieven Marchand <mal@wyrd.be> - 2012-06-09 17:24 +0200
        Re: Have we reached the asymptotic plateau of innovation in programming languages torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-06-11 13:41 +0200
          Re: Have we reached the asymptotic plateau of innovation in programming languages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-06-11 22:13 +0000
            Re: Have we reached the asymptotic plateau of innovation in programming languages "robin" <robin51@dodo.com.au> - 2012-06-13 01:16 +1000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-03-08 19:54 +0000
    Re: Have we reached the asymptotic plateau of innovation in programming language design? George Neuner <gneuner2@comcast.net> - 2012-03-08 17:41 -0500
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Ian Lance Taylor <ian@airs.com> - 2012-03-08 17:02 -0800
      Re: Have we reached the asymptotic plateau of innovation in programming language design? Cameron McInally <cameron.mcinally@nyu.edu> - 2012-03-08 23:40 -0500
        Re: Have we reached the asymptotic plateau of innovation in programming language design? thomas.mertes@gmx.at - 2012-03-11 07:33 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? Michael Dunlavey <mikedunlavey44@gmail.com> - 2012-03-09 16:07 -0500
      Re: Have we reached the asymptotic plateau of innovation in programming language design? BGB <cr88192@hotmail.com> - 2012-03-09 21:14 -0700
    Re: Have we reached the asymptotic plateau of innovation in programming language design? Rock Brentwood <federation2005@netzero.com> - 2012-03-17 12:31 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? BGB <cr88192@hotmail.com> - 2012-03-18 02:35 -0700
      Re: Have we reached the asymptotic plateau of innovation in programming language design? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-03-18 20:35 +0100

Page 1 of 3  [1] 2 3  Next page →

#479 — Have we reached the asymptotic plateau of innovation in programming language design?

While reading slashdot, I've stumbled on the following blog entry:

Research in Programming Languages
Is there still research to be done in Programming Languages?
http://tagide.com/blog/2012/03/research-in-programming-languages/

Quotes:
- But the truth of the matter is that ever since I finished my Ph.D. in the
late 90s, and especially since I joined the ranks of Academia, I have been
having a hard time convincing myself that research in PLs is a worthy
endeavor.
- And herebs the first itchy point: there appears to be no correlation
between the success of a programming language and its emergence in the form
of someonebs doctoral or post-doctoral work. This bothers me a lot, as an
academic. It appears that deep thoughts, consistency, rigor and all other
things we value as scientists arenbt that important for mass adoption of
programming languages.
- And, finally, all of these new languages, even when created over a week as
someone's pet project, sit on the shoulders of all things that existed
before. This leads me to the second itch: one striking commonality in all
modern programming languages, especially the popular ones, is how little
innovation there is in them!
- So one pertinent question is: given that not much seems to have emerged
since 1979 (that's 30+ years!), is there still anything to innovate in
programming languages? Or have we reached the asymptotic plateau of
innovation in this area?

So, what are your views on this subject?

Rui Maciel
[Personally, I'd say there's been precious little new in programming
languages since Simula gave us OOP in the late 1960s.  In your responses,
please remember this is comp.compilers, not comp.semicolon-placement.flame.
-John]

[toc] | [next] | [standalone]

#480

On 3/7/2012 7:52 AM, Rui Maciel wrote:
> - And herebs the first itchy point: there appears to be no correlation
> between the success of a programming language and its emergence in the form
> of someonebs doctoral or post-doctoral work. This bothers me a lot, as an
> academic. It appears that deep thoughts, consistency, rigor and all other
> things we value as scientists arenbt that important for mass adoption of
> programming languages.

I think what is need for mass adoption is the following:
1. Robust implementations that are comparable in speed and power to what
exists.
2. Intuitive syntax to programmers. This probably explains why APL never
caught on :-)
3. Ability to interface with existing code.
4. Proof that the code can solve real problems. If you can give people a
fully-featured web browser in language X, you're probably going to be
able to build more adoption than if the largest program is a calculator.

> - And, finally, all of these new languages, even when created over a week as
> someone's pet project, sit on the shoulders of all things that existed
> before. This leads me to the second itch: one striking commonality in all
> modern programming languages, especially the popular ones, is how little
> innovation there is in them!

I've also noticed that, with the exception of the languages which are
effectively pioneers (FORTRAN, LISP), none of the modern major languages
are the first to develop the techniques they used. This may be because
people are predisposed to not trust research-quality software.

> - So one pertinent question is: given that not much seems to have emerged
> since 1979 (that's 30+ years!), is there still anything to innovate in
> programming languages? Or have we reached the asymptotic plateau of
> innovation in this area?

If you can view it as a PL concern, the modern memory model of C11,
C++11 and Java 5 is new.

The biggest thing that I think needs innovation is parallel programming:
we're still waiting for the innovation like OOP that makes large
commercial parallel programs (leaving aside HPC as wanting something
different) much easier to program. After that, I think more expressive
type systems could be another fruitful field of research, although it
requires care to make sure that the errors they produce are easily
understood by the lay programmer (think of how confusing most people
find C++'s template error messages).

Another thing--this really isn't innovation, though--that people
proposing new languages need to pay attention to both the features and
misfeatures in the programming languages people use. I think PHP is
evidence that trying to under-the-hood sanitize input to prevent
unintentional exploits is prone to backfiring spectacularly. On the
other hand, coercing string types to be UTF-8 or UTF-16 is probably a
bare necessity for any new programming language.

A final thought I had was the idea of source-to-source translation tools
to help migrate code written in $OLD_LANGUAGE to $NEW_LANGUAGE. Again,
not strictly PL, nor is it truly new, but I think it's a place that
could use some more work.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
[Source translators are very old.  I used one in about 1969 that translated
Fortran 66 to PL/I on IBM mainframes.  It worked, but the code was very ugly
due to minor semantic differences between similar constructs like format
statements.  With the improvements in program analysis in the past 30 years,
I suppose it's possible that a translator could identify situations where
the differences don't matter and emit simpler code. -John]

[toc] | [prev] | [next] | [standalone]

#505

Joshua Cranmer <Pidgeot18@verizon.invalid> writes:


> I think what is need for mass adoption is the following:

> 1. Robust implementations that are comparable in speed and power to what
> exists.

The success of languages like Ruby and Perl have shown that this is
not a requirement.  Both languages (at the time they caught on) had
shoddy compilers that generated horribly slow code.  They still
haven't escaped this completely, though the situation is improved.

> 2. Intuitive syntax to programmers. This probably explains why APL never
> caught on :-)

Saying that APL never caught on i wrong: It was one of the ten most used
languages for a long time, and it is still used in many places.
Additionally, it has influenced the design of many later languages
(though these have tended to use ASCII syntax).  But with the increasing
use of UNICODE, non-ASCII syntax might well see a renaissance.

As for what intuitive syntax means, this is debatable.  You seem to mean
"familiar", which certainly applies to why C-like syntax was used for
Java -- the syntax was chosen to be familiar to programmers who had used
C.  Later C# used the same syntax to be familiar to Java programmers.

But intuitive syntax can also mean consistent, unambiguous and without
arbitrary restrictions, which certainly does not apply to C-style
syntax.  In a way, APL syntax is very intuitive: Operators are single
characters, so you dont have problems parsing things like a+++b, where
it is not clear where one operator ends and the next begins, evaluation
order is consistent and there are few special cases.

> 3. Ability to interface with existing code.

This is, I agree, important.  But with standardised multilingual
protocols like Thrift, this is fairly easy to add afterwards.

> 4. Proof that the code can solve real problems. If you can give people a
> fully-featured web browser in language X, you're probably going to be
> able to build more adoption than if the largest program is a calculator.

That, on the other hand, is rarely important.  What is more important is
if the language is used as the standard language in a system that many
people care about.  C rode on the popularity of UNIX, Ruby on the
popularity of Rails, and so on.  Getting pushed by a major industry
player is also important.  This is how PL/I, Java and C# became popular.
If, say, Apple decided that the way to program iOS in the future would
be in a variant of Prolog, this variant would certainly become popular.

A language can also gain adoption if it is used for teaching at a large
number of institutions.  You can argue that is how Pascal, ML, Scheme
and Haskell gained adoption.  While they are known mainly as teaching
languages, all have a nontrivial industrial adoption, mainly in places
that were started by academics and who mainly hire academics as
programmers.

	Torben

[toc] | [prev] | [next] | [standalone]

#513

On Wed, 14 Mar 2012 09:51:31 +0100, torbenm@diku.dk (Torben Fgidius
Mogensen) wrote:

[snip]

>But intuitive syntax can also mean consistent, unambiguous and without
>arbitrary restrictions, which certainly does not apply to C-style
>syntax.  In a way, APL syntax is very intuitive: Operators are single
>characters, so you dont have problems parsing things like a+++b, where
>it is not clear where one operator ends and the next begins, evaluation

     Greedy parsing.  Fornm the longest token.  That is
          a ++ + b

>order is consistent and there are few special cases.

     IIRC, APL had some operators formed by use of backspace.

     APL's right-to-left expression evaluation is unusual.

[snip]

Sincerely,
Gene Wirchenko
[All APL operators are single characters, but given the limitations of
Selectric typewriters and keyboards, they composed some of them by
overstriking.  APL doesn't evaluate from right to left, it groups from
right to left, which is different.  The evaluation order within an
expression is generally invisible to the programmer unless you do
squirelly things with embedded assignments. -John]

[toc] | [prev] | [next] | [standalone]

#516

Gene Wirchenko <genew@ocis.net> writes:

> On Wed, 14 Mar 2012 09:51:31 +0100, torbenm@diku.dk (Torben Fgidius
> Mogensen) wrote:
>
>>But intuitive syntax can also mean consistent, unambiguous and without
>>arbitrary restrictions, which certainly does not apply to C-style
>>syntax.  In a way, APL syntax is very intuitive: Operators are single
>>characters, so you dont have problems parsing things like a+++b, where
>>it is not clear where one operator ends and the next begins, evaluation
>
>      Greedy parsing.  Fornm the longest token.  That is
>           a ++ + b

Indeed.  But that requires knowledge of lexing/parsing methods, so it
is confusing to a newbie programmer, and even some not-so-newbie
programmers can get confused.  A programming language should primarily
be easy to read (parse) by a human reader and only secondarily be easy
to parse by a computer.  Ambiguity is a problem for both, but long
lookahead is usually not a problem for human readers, but may
challenge some parsing methods.  Having a huge hierarchy of operator
precedences is no problem for most parsing methods (certainly not
LR-based methods), but it can make programs hard to read for humans.
C++ has (IMO) gone over the top with the number of predefined
operators and precedence levels.

Most programmers have no problem with the four arithmetic operators, and
can fairly easily also remember the precedences of comparison operators
and logical connectives.  So an idea (employed by, IIRC, OCaml) is to
let operators have a precedence that is determined by their first
character.  So +. has the same precedence as + and so on.  That is a
fairly neat idea, and by allowing all combinations of characters from a
subset of the non-alphanumeric characters in operator names, you also
avoid C's problem of parsing +++: It is parsed as a single operator, and
if it is not defined in the program, that is reported as an error.

	Torben

[toc] | [prev] | [next] | [standalone]

#517

On Wed, 21 Mar 2012 11:53:35 +0100, Torben Fgidius Mogensen wrote:

> That is a
> fairly neat idea, and by allowing all combinations of characters from a
> subset of the non-alphanumeric characters in operator names, you also
> avoid C's problem of parsing +++: It is parsed as a single operator, and
> if it is not defined in the program, that is reported as an error.

A better approach is restricted association rules requiring explicit
brackets when some operands are shared by some operators. Typically it is
the cases like:

   A and B or C
   -x^y

etc. This method will work here as well. Provided, there are

1. infix +
2. prefix ++
3. postfix ++

The rule would be that 1 cannot be associated with either 2 or 3. This
would make both interpretations illegal:

   a ++ + b   (a is shared by 3 and 1)
   a + ++ b   (b is shared by 1 and 2)

So the programmer would have to use brackets to disambiguate:

   (a++) + b
   a + (++ b)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#519

Torben Fgidius Mogensen <torbenm@diku.dk> wrote:
>A programming language should primarily be easy to read (parse) by a
>human reader and only secondarily be easy to parse by a computer.

yay!

[toc] | [prev] | [next] | [standalone]

#514

Joshua Cranmer <Pidgeot18@verizon.invalid> wrote:

> The biggest thing that I think needs innovation is parallel programming:
> we're still waiting for the innovation like OOP that makes large
> commercial parallel programs (leaving aside HPC as wanting something
> different) much easier to program.

Can you characterize non-HPC parallelism? Why is it different? What are
the problems to be addressed?

Victor.
--
Victor Eijkhout -- eijkhout at tacc utexas edu

[toc] | [prev] | [next] | [standalone]

#515 — Re: HPC and parallel programming, was Have we reached the asymptotic

On 2012-03-19, Victor Eijkhout <eijkhout@tacc.utexas.edu> wrote:
>> The biggest thing that I think needs innovation is parallel programming:
>> we're still waiting for the innovation like OOP that makes large
>> commercial parallel programs (leaving aside HPC as wanting something
>> different) much easier to program.
>
> Can you characterize non-HPC parallelism?

Productivity before performance.

> Why is it different?

HPC is more performance before productivity.

> What are the problems to be addressed?

Most programming is sequential. There is no general method to change a
sequential program into a parallel one, and even the methods for
specific problems domains that are there require a high programmer
skill/experience level, and is then still laboursome and risky.

This makes workers more expensive and takes longer training, with
potential retraining needed for a different problem domain.

[toc] | [prev] | [next] | [standalone]

#481 — Have we reached the asymptotic plateau of innovation in programming la

>Personally, I'd say there's been precious little new in programming
>languages since Simula gave us OOP in the late 1960s.

Yes, and milestones prior to that were

assembly language - easier than binary coding
COBOL - promoting the use of descriptive identifiers

And some later significant developments were

C language - standardizing the syntax of procedural programming
Wintel - standardizing the sub-programming language layer

http://slkpg.byethost7.com

[Some of us who programmed in ANSI Standard Fortran 66 and PL/I 76
might take issue with the claim that C standardized procedural
programming. Standard high level procedural interfaces to operating
systems aren't new either, Burroughs had them in Algol in the 1960s.
-John]

[toc] | [prev] | [next] | [standalone]

#489 — Re: Have we reached the asymptotic plateau of innovation in programming la

On 3/8/2012 8:21 AM, SLK Systems wrote:
>> Personally, I'd say there's been precious little new in programming
>> languages since Simula gave us OOP in the late 1960s.

> Yes, and milestones prior to that were

...

> C language - standardizing the syntax of procedural programming
> Wintel - standardizing the sub-programming language layer

...

> [Some of us who programmed in ANSI Standard Fortran 66 and PL/I 76
> might take issue with the claim that C standardized procedural
> programming. Standard high level procedural interfaces to operating
> systems aren't new either, Burroughs had them in Algol in the 1960s.
> -John]

I think the claim was not that C standardized procedural programming,
but rather that it standardized the syntax.

for example, C++, Java, and C#, all use a very similar core syntax to C.
many other modern languages more or less borrow elements of C's syntax
(for example, JavaScript and ActionScript syntax is still fairly close,
as are many parts of PHP syntax, ...).


granted, one can argue:
maybe C syntax followed from languages like PL/I and ALGOL, but between
them and C, there is still a fair bit of a jump, whereas the syntax
differences between, say, C and many of the languages which followed
after it were considerably less drastic.

OTOH, it is a little harder to find languages with syntax more obviously
derived from Fortran or PL/I than from C.


but, I think the issue mostly is that both "innovation" and "pure
research" are often over-rated, and what is needed at this point may not
be the creation of fundamentally new (or even entirely consistent)
languages, but rather refinement, integration, and adaptation to new
domains.

at this point, mainstream languages are still struggling to incorporate
many features (such as closures) which have been known in other
languages for decades.

for example, both C++ and Java have recently added closures, and in both
cases, they come off as fairly poor attempts at doing so.


so, better I think is trying to invest effort in creating "solid"
languages which can effectively integrate much of what exists and seems
to work well in-general, even at the cost of many of the more
academically inclined are liable to make accusations of "blub" at such
things (mostly due to things like syntactic and semantic similarity with
mainstream languages).

it is kind of harder being a language designer who doesn't particularly
value novelty (people often refer to it as "innovation", but I
personally see true innovation as finding a better way to approach a
problem, rather than that of being needlessly different).

I guess it is also mixed with the problem of many people confusing
interface for its implementation, thinking that if something looks a
certain way it must also be implemented a certain way, or conversely
that if something looks different it must also be conceptually different
as well.

I also tend to see needless minimalism as, well, needless. simpler
syntax doesn't mean a simpler or easier to use language, and more so
doesn't mean a simpler implementation.

some people also make accusations of "keeping every onion", but as I see
it, keeping common syntax and features by no means implies that one
slavishly follows every possible rule.

likewise goes for, on the other side, refusing to adopt some particular
library or implementation of a feature does not mean one is
automatically "creating a standard of non-standard" (seriously? can't
one implement something as they see fit without everyone automatically
assuming that it is necessarily broken and/or incompatible with existing
implementations?).

likewise, can't a person be free to pick and choose things as they seem
useful, reusing any old parts which seem useful, and creating new parts
and technologies if/when it seems these could be more useful?


like, just because it looks sort of like mainstream languages, doesn't
mean that it inherits all of their semantic limitations as well, nor
necessarily uses the same scope model, nor even that the treatment of
statements and expressions is the same.


for example (in my language):
I use a delegation-based scope model (more like that in Self), rather
than strict lexical scoping (lexical scoping is still present though);
the line between statements and expressions is much more lax
(semantically, nearly everything is an expression);
the object model is different in many ways (it is neither strictly
Class/Instance nor Prototype OO);
the typesystem isn't strictly normal either (it uses a mix of static,
dynamic, and inferred types, and the type-system is more of a hybrid of
a Scheme-like and C-like type-system than it is "one or the other");
...


but, practically, a person can still write code like they would in a
more conventional language, and it will still work mostly as expected
(most added features are mostly non-intrusive: if you don't use it, you
don't need to deal with it).

for example, unless one goes and writes a piece of code making use of
it, the differences between lexical and delegation-based scoping are not
likely to be obvious, at least until one starts daisy-chaining objects
and environment frames together (this is actually how my VM implements
packages and importing, FWIW). in-fact, it is possible to link ones'
scoping into a cyclic graph as well, and the VM allows this (it detects
and ignores cycles in the scope graph).

so, a unified model exists, and on the surface, it is exposed (in a
"weaker" form) via the syntactic sugar known as "packages" and "imports"
("namespaces" and "using" in C# or C++ terms), but, if a person wants,
they can use a few modifiers and start directly using the underlying
semantic model as well (similar goes for classes: they are partly "real"
classes, and are partly syntax sugar over a Prototype-OO based model).

there are also many other types of syntax sugar as well (properties,
operator overloading, ...).

...


but, many people apparently see a C-family syntax and automatically
judge it negatively as a result, whereas I happen to feel that the
syntax works fairly well and personally see no "obviously better"
solution (either functionally or aesthetically).

but, I saw little reason to break things which, IMO, actually tend to
work fairly well.


ironically though, I don't have "user defined syntax", but this is
partly as I personally felt that this one is a misfeature (I see more
potential drawbacks than merits regarding this one).


now, whether or not there is much value in being a language
designer/implementer is a secondary issue.

ultimately, a language needs to effectively serve my own uses before it
can have much hope of being useful to anyone else. I have no personal
need or expectation to "change the world".

and, even if none of the features are terribly original, where is the
problem?

[toc] | [prev] | [next] | [standalone]

#494 — Re: Have we reached the asymptotic plateau of innovation in programming la

BGB <cr88192@hotmail.com> wrote:

(snip)

> but, I think the issue mostly is that both "innovation" and "pure
> research" are often over-rated, and what is needed at this point may not
> be the creation of fundamentally new (or even entirely consistent)
> languages, but rather refinement, integration, and adaptation to new
> domains.

It seems to me that this is a big reason why we have the different
languages that we do, and why we will never converge onto only one.

Different needs are better met, in some cases, with different ways of
expressing those needs.

(snip on closures)

> so, better I think is trying to invest effort in creating "solid"
> languages which can effectively integrate much of what exists and seems
> to work well in-general, even at the cost of many of the more
> academically inclined are liable to make accusations of "blub" at such
> things (mostly due to things like syntactic and semantic similarity with
> mainstream languages).

PL/I, the original all-in-one language, is still used, but much less
often than some others. Among its goals, was to replace Fortran.

Now, with Fortran 2003 and Fortran 2008, a large fraction of the PL/I
features have been included, and more.

(snip)
> I also tend to see needless minimalism as, well, needless. simpler
> syntax doesn't mean a simpler or easier to use language, and more so
> doesn't mean a simpler implementation.

That seems, to me, hard to say. Too many features make a language too
hard to remember, requiring more reference to documentation while
programming. But also, as you indicate, needless minimalism doesn't
help. It can make it harder to do some simple operations.

> some people also make accusations of "keeping every onion", but as I
> see it, keeping common syntax and features by no means implies
> that one slavishly follows every possible rule.

PL/I included many features from Fortran, COBOL, and ALGOL, but
overall kept a nice, consistent, usage. Very few of what seem to be
arbitrary restrictions.

Fortran, on the other hand, even as it has evolved has kept many
restrictions that seem strange.

(snip)

> but, many people apparently see a C-family syntax and automatically
> judge it negatively as a result, whereas I happen to feel that the
> syntax works fairly well and personally see no "obviously better"
> solution (either functionally or aesthetically).

Well, reserved words do make it hard to extend a language and
stay compatible with older programs.

(snip)

-- glen

[toc] | [prev] | [next] | [standalone]

#497 — Re: Have we reached the asymptotic plateau of innovation in programming la

On 3/12/2012 12:42 AM, glen herrmannsfeldt wrote:
> BGB<cr88192@hotmail.com>  wrote:
>
> (snip)
>
>> but, I think the issue mostly is that both "innovation" and "pure
>> research" are often over-rated, and what is needed at this point may not
>> be the creation of fundamentally new (or even entirely consistent)
>> languages, but rather refinement, integration, and adaptation to new
>> domains.
>
> It seems to me that this is a big reason why we have the different
> languages that we do, and why we will never converge onto only one.
>
> Different needs are better met, in some cases, with different ways of
> expressing those needs.

granted, at least in the near term.

it does seem however, that on average, languages are becoming gradually
more general purpose, and the distance between "different" languages
seems to be gradually shrinking.

eventually, there may be some sort of convergence, but I think it is
more likely to be a sort of gradual and natural process. all dominant
languages become so close as to be virtually or practically identical,
rather than as some sort of more dramatic "one language to rule them
all" event.

in such a scenario, language convergence will have been so widespread
that people may have, by this point, ceased to clarify which language
they were using, since most would have become largely copy-paste
compatible anyways.


>> so, better I think is trying to invest effort in creating "solid"
>> languages which can effectively integrate much of what exists and seems
>> to work well in-general, even at the cost of many of the more
>> academically inclined are liable to make accusations of "blub" at such
>> things (mostly due to things like syntactic and semantic similarity with
>> mainstream languages).
>
> PL/I, the original all-in-one language, is still used, but much less
> often than some others. Among its goals, was to replace Fortran.
>
> Now, with Fortran 2003 and Fortran 2008, a large fraction of the PL/I
> features have been included, and more.

yes, ok.


> (snip)
>> I also tend to see needless minimalism as, well, needless. simpler
>> syntax doesn't mean a simpler or easier to use language, and more so
>> doesn't mean a simpler implementation.
>
> That seems, to me, hard to say. Too many features make a language too
> hard to remember, requiring more reference to documentation while
> programming. But also, as you indicate, needless minimalism doesn't
> help. It can make it harder to do some simple operations.


well, I think it depends some on how much simplicity or complexity (or
minimalism, or not) is in question.

for example, JavaScript is fairly small/simple if compared with C, Java,
or C#.
OTOH, it is fairly large and complex if compared with Scheme or Self.


what about a language which is more complex than JavaScript, maybe
roughly on-par with C or Java, and generally simpler than C++ and C# ?
what about a VM where the bytecode has 100s of unique operations?
...


but, OTOH:
in a language like JavaScript you can type "a+b*c", and get the expected
precedence.


this is different than typing, say (in Scheme):
"(+ a (* b c))"
or (in Self):
"b * c + a" (noting that "a + b * c" will give a different answer).


as I see it, the sorts of minimalism where one can't "afford" to have
things like operator precedence, or including conventional control-flow
mechanisms, is needless minimalism.

most real programmers have better things to do than sit around working
around awkward ways of expressing arithmetic, and figuring out how to
accomplish all of their control flow via recursion and if/else (and so
help you if you want something like sane file IO, or sockets, or
threads, ...).

(and, it is not necessarily a good sign when things like loops, file IO,
arrays, ... are supported by an implementation as... language
extensions...).


but, many people hate on C and C++ and so on, claiming that languages
"should" have such minimalist syntax and semantics. however, such
minimalist languages have generally failed to gain widespread acceptance.


likewise, although a person can make an interpreter with a small number
of total opcodes, typically this means the program will need a larger
number of them to complete a task, and thus run slower.


for example, a person could make an interpreter with roughly 3 opcodes
which fairly directly implements lambda calculus... but it will perform
like crap.

10 or 15 is a bit better, then one probably at least has "the basics".

with several hundred opcodes, arguably a lot of them are "redundant",
being easily expressible in terms of "simpler" opcodes, but at the same
time, a single opcode can express what would otherwise require a chain
of simpler opcodes.

like, "wow, there is this here 'lpostinc' opcode to load a value from a
variable and store an incremented version of the value back into the
variable". is this opcode justified vs, say: "load x; dup; push 1;
binary add; store x;"? I figure such cases are likely justified (they do
tend to show favorably in a benchmark).


OTOH, a person can go too far in the other direction as well.


>> some people also make accusations of "keeping every onion", but as I
>> see it, keeping common syntax and features by no means implies
>> that one slavishly follows every possible rule.
>
> PL/I included many features from Fortran, COBOL, and ALGOL, but
> overall kept a nice, consistent, usage. Very few of what seem to be
> arbitrary restrictions.
>
> Fortran, on the other hand, even as it has evolved has kept many
> restrictions that seem strange.


yep.

in my case, it was more about an ECMAScript-family language
incorporating some features from languages like ActionScript, Java, C#
and C++, among them: packages, classes, properties, pass-by-value
objects (structs and value-classes), ...

however, as I have seen it, I haven't really inherited their limitations.

for example, the language still supports loading from source, eval, ...
even despite incorporating features from languages which use static
compilation.

the implication is that if one borrows features from a traditionally
statically-compiled language, one will also inherit its limitations,
somehow forcing static compilation and an inability to use late-binding
or something, but this isn't really the case. like, people believe there
is some sort of mutual exclusion thing going on, like for every feature
one adds some other feature has to be removed or something?...


likewise, despite adding support for type annotations and classes, both
dynamic types and ex-nihilo objects still continue to work.

and, at the same time, there are value classes which may have things
like copy-constructors and destructors (but, at the same time, how they
work internally differs somewhat from the C++ analogue).


but, such things provoke negative commentary (value-classes are an
example of such an "onion").

but, I don't think it is too severe of an issue, or even that the
language complexity is necessarily even all that bad, granted, the
language makes no claim of being "minimal" either, which is the issue.


> (snip)
>
>> but, many people apparently see a C-family syntax and automatically
>> judge it negatively as a result, whereas I happen to feel that the
>> syntax works fairly well and personally see no "obviously better"
>> solution (either functionally or aesthetically).
>
> Well, reserved words do make it hard to extend a language and
> stay compatible with older programs.


a lot depends on how much of a legacy codebase their is, and how likely
the words are to clash, and how "severe" code-breaking scenarios would be.

in my case, the vast majority of reserved words came from "sibling"
languages, with relatively few "original" reserved words, although there
are some (fun/quote/unquote/... being notable examples). some others,
like "value_class", are unlikely to be used as names.

many borrowed reserved words have similar meaning as in their source
languages, but some others have somewhat different meanings. for
example, the "delegate" modified does something very different in my
language than it does in C# (which in my language is more handled by a
piece of syntax known as "typedef function ...", where ironically
"typedef" is used but is also behaviorally somewhat different from in C
or C++).

but (in BGBScript):
"typedef function foo(x:int):void;"
does something sort of like (in C#):
"delegate void foo(int x);"
and sort of like (in C):
"typedef void (*foo)(int x);"

which is very likely "good enough":
and the subtle differences are about like asking "in which ways is void
a value type or not a value type?".


at the same time, there is a relative lack of legacy code, and even less
that I really have to worry too much about breaking.


longer term, what will be the result of this? well, this will be an
issue for the future to deal with.

[toc] | [prev] | [next] | [standalone]

#502 — Re: Have we reached the asymptotic plateau of innovation in programming la

BGB <cr88192@hotmail.com> wrote:

(snip)
> in such a scenario, language convergence will have been so widespread
> that people may have, by this point, ceased to clarify which language
> they were using, since most would have become largely copy-paste
> compatible anyways.

Well, first there is the division between interpreted languages, such
as Mathematica, Matlab, S/R, ..., and for that matter, Excel, that are
good for quick one time problems, and compiled languages that are
faster when you want to do something many times.

It seems to me that division will stay, though the languages could
still tend to converge.

(snip)

> what about a language which is more complex than JavaScript, maybe
> roughly on-par with C or Java, and generally simpler than C++ and C# ?
> what about a VM where the bytecode has 100s of unique operations?
> ...

The bytecode question should be independent of the language, and
should be optimized, as RISC processors are, for compiler generated
code instead of human written assembly code.

> but, OTOH:
> in a language like JavaScript you can type "a+b*c", and get the expected
> precedence.

> this is different than typing, say (in Scheme):
> "(+ a (* b c))"
> or (in Self):
> "b * c + a" (noting that "a + b * c" will give a different answer).

Well, first there are a number of precedence cases in C that many
would have done differently. But also there is the question of which
should be an operator and which a function. Note that C has the %
operator and pow() function, where Fortran has mod() and **.

> as I see it, the sorts of minimalism where one can't "afford" to have
> things like operator precedence, or including conventional control-flow
> mechanisms, is needless minimalism.

Then there are funny little differences, where language designers try
to force a programming style. Fortran added the ability to use
floating point variables as DO loop variables in Fortran 77, then took
it away again in Fortran 90.

Another difference is the abilty to use array or structure expressions
instead of explicit loops.

> most real programmers have better things to do than sit around working
> around awkward ways of expressing arithmetic, and figuring out how to
> accomplish all of their control flow via recursion and if/else (and so
> help you if you want something like sane file IO, or sockets, or
> threads, ...).

But each time you make something easier to use, something else usually
gets at least slightly harder. You don't really want 200 different
operators, with way too many precedence levels. It is just too hard
for humans, not that it bothers compilers much at all.

> (and, it is not necessarily a good sign when things like loops, file IO,
> arrays, ... are supported by an implementation as... language
> extensions...).

Well, yes, but how many different loop constructs do you need?

> but, many people hate on C and C++ and so on, claiming that languages
> "should" have such minimalist syntax and semantics. however, such
> minimalist languages have generally failed to gain widespread acceptance.

> likewise, although a person can make an interpreter with a small number
> of total opcodes, typically this means the program will need a larger
> number of them to complete a task, and thus run slower.

OK, but high-level language design should be toward making things
easier for humans. Unless there is a big trend back toward assembly
programming, instruction sets, including byte-code interpreters, should
be designed for faster machine processing, and not for people.

(It is useful in debugging if it isn't too hard for humans to read,
but most of the time that shouldn't be needed.)

> for example, a person could make an interpreter with roughly 3 opcodes
> which fairly directly implements lambda calculus... but it will perform
> like crap.

> 10 or 15 is a bit better, then one probably at least has "the basics".

Well, you can have the data tagged such that only one add instruction
is needed to add any size or type (byte, short, int, long, float,
double, etc.) or separate opcodes for each. It doesn't make a huge
difference, but likely you could see the performance difference.

> with several hundred opcodes, arguably a lot of them are "redundant",
> being easily expressible in terms of "simpler" opcodes, but at the same
> time, a single opcode can express what would otherwise require a chain
> of simpler opcodes.

The RISC vs. CISC argument in processor architecture.

> like, "wow, there is this here 'lpostinc' opcode to load a value from a
> variable and store an incremented version of the value back into the
> variable". is this opcode justified vs, say: "load x; dup; push 1;
> binary add; store x;"? I figure such cases are likely justified (they do
> tend to show favorably in a benchmark).


> OTOH, a person can go too far in the other direction as well.

Like VAX.

(snip)

-- glen

[toc] | [prev] | [next] | [standalone]

#506 — Re: Have we reached the asymptotic plateau of innovation in programming la

On 3/13/2012 10:19 PM, glen herrmannsfeldt wrote:
> BGB<cr88192@hotmail.com>  wrote:
>
> (snip)
>> in such a scenario, language convergence will have been so widespread
>> that people may have, by this point, ceased to clarify which language
>> they were using, since most would have become largely copy-paste
>> compatible anyways.
>
> Well, first there is the division between interpreted languages, such
> as Mathematica, Matlab, S/R, ..., and for that matter, Excel, that are
> good for quick one time problems, and compiled languages that are
> faster when you want to do something many times.
>
> It seems to me that division will stay, though the languages could
> still tend to converge.
>

there are languages that straddle the border, such as JavaScript and
ActionScript, where the language use ranges from purely interpreted
(such as a naive JavaScript implementation), to statically-compiled
(some uses of Flash and Flex apparently have people compiling
ActionScript into native code, in addition to past versions of Flash
using an interpreter and newer versions using a JIT).

so, it may be more a matter of tiny DSLs vs larger general-purpose
languages, than of compiled-vs-interpreted languages.


many DSLs may be interpreted, yes, but some may also be compiled.
likewise, some industrial-strength / "compiled" languages, such as Java,
C, and C++, may sometimes (if rarely) be run within an interpreted
environment.


> (snip)
>
>> what about a language which is more complex than JavaScript, maybe
>> roughly on-par with C or Java, and generally simpler than C++ and C# ?
>> what about a VM where the bytecode has 100s of unique operations?
>> ...
>
> The bytecode question should be independent of the language, and
> should be optimized, as RISC processors are, for compiler generated
> code instead of human written assembly code.
>

it typically is focused on compiler output.

the bytecode is actually somewhat specialized for the compiler output,
and has a number of opcodes mapping to high-level language constructs.
however, as-is, there is a reasonably tight language/bytecode coupling,
but this is planned to be relaxed some (eventually...).


a particular example in my case (mentioned previously) was "lpostinc"
(along with "lpostinc_fn"), which map, fairly directly, to the
expression "i++" (both for lexical scope, where the latter 'fn' opcode
being for the case when 'i' is known to be an integer or fixnum type).

so, consider a few common cases ('x'=lexical+generic,
'i'=lexical+integer, 'v'=global/package scope, and ';' to mark statement):
inc_s		"v++;" or "++v;"
dec_s		"v--;" or "--v;"
linc		"x++;" or "++x;"
ldec		"x--;" or "--x;"
linc_fn		"i++;" or "++i;"
ldec_fn		"i--;" or "--i;"
postinc_s	"v++"
preinc_s	"++v"
lpostinc	"x++"
lpreinc		"++x"
lpostinc_fn	"i++"
lpreinc_fn	"++i"
postdec_s	"v--"
predec_s	"--v"
...

however, this level of specificity helps somewhat when one is dealing
with a plain interpreter, since many of these operations are fairly
common, and dedicating more opcodes to these special cases helps reduce
passes through the interpreter loop (as well as the number of push/pop
operations on the stack, ...).

for example, one can note the absence of float-specialized versions, but
there is a reason: because "++" and "--" are very rarely used on floats
(however, there are float specialized versions of many other ops).

likewise, there are some similar combinations for things like
load+compare+jump as well.

for example, "if(i>j)" can be encoded as a single bytecode operation.

also some opcodes dedicated to implementing "switch()" as well (after
noting that each "case" ended up producing a 3 opcode chain which could
be collapsed to 1 opcode, ...).


but, yes, if one follows these sorts of patterns, it is not hard to
figure out why there are 100s of opcodes (errm... closer to about 500 at
present).

most recent additions have been more narrowly focused though, mostly
related to adding new functionality, rather than related to
micro-optimizing things.


>>but, OTOH:
>> in a language like JavaScript you can type "a+b*c", and get the expected
>> precedence.
>
>> this is different than typing, say (in Scheme):
>> "(+ a (* b c))"
>> or (in Self):
>> "b * c + a" (noting that "a + b * c" will give a different answer).
>
> Well, first there are a number of precedence cases in C that many
> would have done differently. But also there is the question of which
> should be an operator and which a function. Note that C has the %
> operator and pow() function, where Fortran has mod() and **.
>

but, having precedence is different than not having precedence (say,
requiring parens for everything, or everything being left-associative...).

people at least sort of expect PEMDAS to be followed, even if yes, the
standard C family operator precedences are far from ideal (it is mostly
a matter of leaving them as-is, and have stupid precedence, or changing
them and have an increased risk of people writing code which breaks
because it had assumed the standard C-style operator precedences).


>> as I see it, the sorts of minimalism where one can't "afford" to have
>> things like operator precedence, or including conventional control-flow
>> mechanisms, is needless minimalism.
>
> Then there are funny little differences, where language designers try
> to force a programming style. Fortran added the ability to use
> floating point variables as DO loop variables in Fortran 77, then took
> it away again in Fortran 90.
>

both C-family languages and my language allow using whatever for looping
will go there (could be an integer, or floats, or walking over
characters in a string, ...).


> Another difference is the abilty to use array or structure expressions
> instead of explicit loops.
>

yes.

C family languages have traditionally not had this, but in newer ones
there is "foreach()" or "for(...in...)".


>> most real programmers have better things to do than sit around working
>> around awkward ways of expressing arithmetic, and figuring out how to
>> accomplish all of their control flow via recursion and if/else (and so
>> help you if you want something like sane file IO, or sockets, or
>> threads, ...).
>
> But each time you make something easier to use, something else usually
> gets at least slightly harder. You don't really want 200 different
> operators, with way too many precedence levels. It is just too hard
> for humans, not that it bothers compilers much at all.
>

fair enough.

"the basics" are needed though.


>> (and, it is not necessarily a good sign when things like loops, file IO,
>> arrays, ... are supported by an implementation as... language
>> extensions...).
>
> Well, yes, but how many different loop constructs do you need?
>

probably all the standard ones:
"for()", "while()", "do ... while();", ...

ideally also with "break" and "continue".

when one has to roll their own loops via recursion and conditionals and
similar, it often renders break and continue problematic (the loop
instead becomes an awkward mess of deeply nested if/else chains).


granted, I have before seen people get annoyed at things like doing a
"return" in the middle of a loop, ... but, if the rest of the function
is known to be unnecessary, what is the point of having to wait for it
to reach the end of the function?...

granted, these are probably the same types of people who complain about
things like "while(i<j)i+=i>>1;" and "(4.0/3)*x/(1<<i)" and similar as well.


>> but, many people hate on C and C++ and so on, claiming that languages
>> "should" have such minimalist syntax and semantics. however, such
>> minimalist languages have generally failed to gain widespread acceptance.
>
>> likewise, although a person can make an interpreter with a small number
>> of total opcodes, typically this means the program will need a larger
>> number of them to complete a task, and thus run slower.
>
> OK, but high-level language design should be toward making things
> easier for humans. Unless there is a big trend back toward assembly
> programming, instruction sets, including byte-code interpreters, should
> be designed for faster machine processing, and not for people.
>
> (It is useful in debugging if it isn't too hard for humans to read,
> but most of the time that shouldn't be needed.)
>

yes.

hence, why there are lots of opcodes:
lots of opcodes means shorter opcode traces, and generally faster
execution by an interpreter.

granted, a JIT doesn't really care so much, but it is easier for a JIT
to decompose complex instructions than it is for an interpreter to
recompose macro-operations from long chains of minimal instructions.


>> for example, a person could make an interpreter with roughly 3 opcodes
>> which fairly directly implements lambda calculus... but it will perform
>> like crap.
>
>> 10 or 15 is a bit better, then one probably at least has "the basics".
>
> Well, you can have the data tagged such that only one add instruction
> is needed to add any size or type (byte, short, int, long, float,
> double, etc.) or separate opcodes for each. It doesn't make a huge
> difference, but likely you could see the performance difference.
>

with 10 or 15 opcode ISAs, typically one has opcodes like "binary" and
"unary" which deal with all binary and unary ops, or (worse yet) they
are implemented as function calls.

my VM uses a mixed strategy, with a larger operator set which is
accessible from the "binary" or "unary" opcodes, a number which are
accessible directly by bytecode ops, and some number which are
type-specialized opcodes.


"add_fn", now it knows that it is both doing an add operation and that
it is dealing with integers, allowing it to skip some amount of internal
logic.

"add", OTOH, tells what operation is being performed, but still requires
additional type-checking.

the main operators with dedicated opcodes are:
binary: add/sub/mul/div, and/or/xor/shl/shr/shrr (int)
unary: pos/neg/not/lnot
conditional: eqv/neqv/eq/neq/lt/gt/le/ge/unord
(eqv/neqv is ==/!=, eq/neq is ===/!==)

in my current (incomplete) JIT, the JIT mostly re-merges them and then
performs more advanced type analysis, but again this level of
specialization can help more with an interpreter, even if mostly
redundant for a JIT.


>> with several hundred opcodes, arguably a lot of them are "redundant",
>> being easily expressible in terms of "simpler" opcodes, but at the same
>> time, a single opcode can express what would otherwise require a chain
>> of simpler opcodes.
>
> The RISC vs. CISC argument in processor architecture.
>

yeah, pretty much.
my design is probably fairly solidly CISC.


I am not sure how directly they compare, but the design as it was mostly
emerged some years back when a past version of my interpreter was stuck
at "the switch limit", which basically means it was bounded primarily by
how rapidly it could spin through a switch block.

finding ways to shorten the chain was the main way of making it faster
(at the time, and was mostly driven by a mix of looking at profiler
output and instruction traces for compiled bytecode).

more recently, this is less of an issue (partly due to me switching to
using threaded code for interpretation instead of a giant switch block),
but it probably still helps some (albeit, according to the profiler most
of the time at present in benchmarks goes apparently into
getting/setting lexical variables and similar).


granted, not everything in that story turned out well:
after my successes (with that particular interpreter, and a short-lived
JIT which followed), I spent several years in a partially
performance-crazed state, writing an ill-fated C compiler and a bunch of
overly complex micro-optimized systems in the process.

(the C compiler project might have turned out better had I made sure the
everything worked solidly before attempting to micro-optimize it, since
it ended up being a mess which ultimately proved beyond my abilities to
debug...).


luckily, not everything turned out all that badly either...

at least I ended up with a spiffy C FFI, and a reasonably fast (if
albeit horridly complicated) Class/Instance OO API.


>> like, "wow, there is this here 'lpostinc' opcode to load a value from a
>> variable and store an incremented version of the value back into the
>> variable". is this opcode justified vs, say: "load x; dup; push 1;
>> binary add; store x;"? I figure such cases are likely justified (they do
>> tend to show favorably in a benchmark).
>
>
>> OTOH, a person can go too far in the other direction as well.
>
> Like VAX.
>

possibly...



hmm, what would be the output for "while(i<j)i+=i>>1;"?...

probably something like (variable indices chosen arbitrarily):
L1: jmp_ge_lfn 1,2,L0
lload_f 1
shr_fnc 1
lload_f 1
add_fn
lstore_f 1
jmp L1
L0:

idle thought, if I had a few more opcodes...
I could shave down the above sequence to, say:
L1: jmp_ge_lfn 1,2,L0
lxl_shr_fnc 1,1
lxs_add_fn 1
jmp L1
L0:

these would likely add a chunk of approx 22-30 new opcodes.

but, alas, I probably have more than enough complex opcodes as-is...

[toc] | [prev] | [next] | [standalone]

#504 — Re: Have we reached the asymptotic plateau of innovation in programming la

BGB <cr88192@hotmail.com> writes:

> it does seem however, that on average, languages are becoming gradually
> more general purpose, and the distance between "different" languages
> seems to be gradually shrinking.

It is true that languages tends to grow over time to the point where
they have everything: Objects, functional values, static types,
dynamic types, lazy evaluation, strict evaluation, pure functions,
impure functions, parametric polymorphish, interfaces, message
passing, query sublanguages, etc., all in one language.  In this
respect, languages tend to grow more general-purpose and more similar.

But at the same time, there is an increasing trend of domain-specific
languages: Languages designed for _very_ specific problem domains.
While these previously usually looked a lot like existing languages
but with a few added constructs or standard data types, they are
increasingly designed from the ground up for supporting the specific
problem domain -- they are often not Turing-complete, and they may
have complex type systems or restrictions that ensure domain-specific
constraints (such as resource usage or analysability).  And they often
have syntax that look nothing like traditional PL syntax.

So the way I see it, there is a widening range of languages from
monstrous general-purpose languages with huge standard libraries to
tiny domain-specific languages with no libraries to speak of and
everything in-between.  And while the languages at one end of the
spectrum tend to converge, the languages at the other end diverge more
and more.

	Torben

[toc] | [prev] | [next] | [standalone]

#500 — Re: Have we reached the asymptotic plateau of innovation in programming languages?

From: "SLK Systems" <slkpg3@gmail.com>
Sent: Friday, 9 March 2012 2:21 AM

> >Personally, I'd say there's been precious little new in programming
>>languages since Simula gave us OOP in the late 1960s.
>
> Yes, and milestones prior to that were
>
> assembly language - easier than binary coding

Then FORTRAN and GEORGE, and probably others,
which improved considerably on machine and assembly languages.

> COBOL - promoting the use of descriptive identifiers
>
> And some later significant developments were
>
> C language - standardizing the syntax of procedural programming

Long before C, Algol was used extensively for public presentation
of algorithms (see Collected Algorithms of the ACM, initially
published in Communications of the ACM);
after Algol came PL/I (which incorporated some good features
of Algol, COBOL, and FORTRAN), then Pascal.

[toc] | [prev] | [next] | [standalone]

#669 — Re: Have we reached the asymptotic plateau of innovation in programming languages

>>Personally, I'd say there's been precious little new in programming
>>languages since Simula gave us OOP in the late 1960s.

The ASCII character set has been a limiting factor for programming
language design for decades.  Here I'm talking about the interface that
faces the programmer, not "language features" that enable buzzword
compliant programming.

Another limiting factor, not readily apparent to North Americans: the
English language.  Most, if not all, programming languages applied world
wide are based on English, with keywords in English.

Different vocabulary and different (natural language) grammar rules make
some things hard to express and sometimes impossible.  English is one of
the most (if not *the* most) verbose languages I know.  It needs a lot
of "small words in between" to make sentences comprehensible while in
other languages it's often enough to change a vowel.

If people are going to *research* programming languages, they should
also be researching the human factor, not brand new buzzword compliant
features.

Some questions I might want to see answered by a language researcher
are:

  What happens when you're no longer restricted by the ASCII character
  set?  Expand that to: What happens when you're no longer restricted by
  Unicode and can invent your own notation and symbols at will?

  What happens when you get to define your own keyboard layout?  Put the
  new symbols anywhere you want.

  What happens if you borrow word alterations from other natural
  languages to your keywords?  Does it makes anything more obvious?
  Harder to read?  Did you manage to invent something "new" like the ? :
  operator from C that enables common patterns to be expressed more
  compactly?

Also, explore literate programming.  Some applications, such as
scientific papers on algorithms are meant for human to human
communication and only incidentally for computers to run too.  When that
is built in a language from the ground up and not crafted on afterwards
with tools like noweb you just might find something to surprise you.

And while you're at it, develop an interface with automatic indentation,
code completion and if possible, refactoring.  Try to make that
interface independent to the compiler.  Does it help this tool if you
add metadata to your object files beyond the regular debugging symbols?
--
   Johann Oskarsson                http://www.2ndquadrant.com/    |[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
                                                                  |
   Blog: http://my.opera.com/myrkraverk/blog/
[If you think English is wordy, you must not know any French, Spanish,
or Italian, all of which are far wordier.  For people who like larger
character sets, you know where to find APL if you want it. -John]

[toc] | [prev] | [next] | [standalone]

#671 — Re: Have we reached the asymptotic plateau of innovation in programming languages

Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> wrote:
>>>Personally, I'd say there's been precious little new in programming
>>>languages since Simula gave us OOP in the late 1960s.

> The ASCII character set has been a limiting factor for programming
> language design for decades.  Here I'm talking about the interface that
> faces the programmer, not "language features" that enable buzzword
> compliant programming.

This has been a problem for PL/I for years. PL/I uses the EBCDIC NOT
character for the logical and relational operators. ASCII doesn't
have the NOT sign. ASCII has tilde and carat that aren't in the usual
EBCDIC character set, so one or the other usually maps to NOT,
but ~= looks more like an approximately equal to operator than a
not equal to operator. (EBCDIC also has a cent sign, which sometimes
maps to/from whichever of tilde and carat don't map to NOT.)

I never especially liked the C ! and != operators, but have gotten
used to them.

> Another limiting factor, not readily apparent to North Americans: the
> English language.  Most, if not all, programming languages applied world
> wide are based on English, with keywords in English.

I have wondered about this for many years. I have asked people whose
native language isn't English, but it doesn't seem to bother them
at all. Of course if I ask them, it is likely that they speak enough
English not to see much of a problem.

Still, I once saw something like:

#define ALLEZA goto

Along a different line:

#define BEGIN {
#define END }

to make C look like Pascal, so maybe

#define FIN }

-- glen

[toc] | [prev] | [next] | [standalone]

#674 — Re: Have we reached the asymptotic plateau of innovation in programming languages

On 6/6/2012 6:40 PM, glen herrmannsfeldt wrote:
>> The ASCII character set has been a limiting factor for programming
>> language design for decades.  Here I'm talking about the interface that
>> faces the programmer, not "language features" that enable buzzword
>> compliant programming.

The biggest problem with going outside of ASCII is that keyboard support
stops being universal, with the lesser issue of character set
proliferation. The standard alphanumeric ASCII characters (and most of
the standard punctuation characters, though some get hard to type IIRC)
are on pretty much every keyboard attached to a modernish computer.

Beyond that, you have issues: people in the US typically don't have easy
access to even basic accented Latin characters like [e with an accent,
which the moderation software smashed -John] (Which, on this
keyboard, required an Alt+numpad combo, necessitating both memorizing
the Unicode value and enabling/disabling the numpad)

Korean keyboards would let you type Hangul more easily, but accented
characters are as, if not more, difficult to type for them. And good
luck if you decide that some keyword needs, say, Ancient Egyptian
Hieroglyphics to be typed in. Sure, you can make the editor do things
for you (this is what happens for APL IIRC), but to most programmers,
it just seems like you're making their lives hard for no reason.

>> Another limiting factor, not readily apparent to North Americans: the
>> English language.  Most, if not all, programming languages applied world
>> wide are based on English, with keywords in English.
>
> I have wondered about this for many years. I have asked people whose
> native language isn't English, but it doesn't seem to bother them
> at all. Of course if I ask them, it is likely that they speak enough
> English not to see much of a problem.

I once recall reading an open source program produced by a Portuguese
university. All local variable names were in Portuguese. Most of the
class and method names were in English.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.compilers

csiph-web