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 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

Joshua Cranmer <Pidgeot18@verizon.invalid> writes:

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

Even with ASCII, keyboard support is not as universal as you may
believe.  The characters [, ], {, }, ~, ^ and \ are placed in an
annoying way on the Icelandic layout.

You need to press right alt (Alt Gr) and press 7, 8, 9, 0 and other keys
on the right side.  Basically, you need to leave the typing position and
move your right hand in unusual ways to achieve the combination.  Using
the left hand to press the key while holding Alt Gr is even slower.

> 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)

Which is why I pointed out keyboard redefinition to potential language
researchers.

>>> 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 don't mind programming in English, I do it all the time.  However if I
were to program in some other language, say Icelandic in an Icelandic
programming language, I expect to be able to use word changes as
dictated by the grammar.

Example in C++ & Java.  Given an object Hulda (a fairly common given
name) I'd want to

  throw Huldu;

for grammatical consistency with Icelandic.  And I'd like to use "kasta"
instead of "throw" of course.

    If you're asking why we would ever want a language where names and
    nouns change according to context the answer is simple: It allows
    shorter sentences.  An introductory tutorial on Latin will
    demonstrate this adequately.

A programming language that allows for word changes according to natural
language grammar?  That's something to study.

                                 <><><>

Another point to make.  Why do we assign from right to left?  Is it in
any way natural?  What's wrong with

  a + b --> c                  "a plus b assigned to c"

instead of

  c <-- a + b                  "c becomes a + b?"

The more I think about it, I believe the former construct is a bit more
natural since we read from left to right.  However, I'd want to see or
work on a non-trivial project in such a language to make up my mind.

For an Arabic programming language, all bets are off.

--
   Johann Oskarsson                http://www.2ndquadrant.com/    |[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
                                                                  |
   Blog: http://my.opera.com/myrkraverk/blog/

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

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

Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> wrote:

(snip)
> Another point to make.  Why do we assign from right to left?  Is it in
> any way natural?  What's wrong with

>  a + b --> c                  "a plus b assigned to c"

> instead of

>  c <-- a + b                  "c becomes a + b?"

Must not be so obvious, as it seems that assemblers I have worked
with have done it both ways.  That is, LOAD or MOVE instructions
that load/move right to left or left to right.

> The more I think about it, I believe the former construct is a bit more
> natural since we read from left to right.  However, I'd want to see or
> work on a non-trivial project in such a language to make up my mind.

It goes at least back to Fortran, I don't know it farther back
than that.

In BASIC, at least slightly modelled after Fortran, there is a keyword
LET for assignment, but it is optional on all systems that I know of.

10  LET C=A+B

There is, on the other hand, the Fortran ASSIGNed GOTO, and the
corresponding ASSIGN statement, which traces back all the way to
Fortran I, which is left to right.

      ASSIGN 12 TO I

The verilog continuous assignment statement uses the assign
keyword, but assigns right to left.

Right to left seems at least slightly more convenient when trying to
find where a variable is changed you can follow down the left side.

> For an Arabic programming language, all bets are off.

Then there are the top to bottom asian languages.

-- glen

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

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

On Thursday 07 Jun 2012 at 18:21, "Johann 'Myrkraverk' Oskarsson"
<johann@2ndquadrant.com> wrote:
> Another point to make.  Why do we assign from right to left?  Is it in
> any way natural?  What's wrong with
>
>   a + b --> c                  "a plus b assigned to c"
>
> instead of
>
>   c <-- a + b                  "c becomes a + b?"
>
> The more I think about it, I believe the former construct is a bit more
> natural since we read from left to right.  However, I'd want to see or
> work on a non-trivial project in such a language to make up my mind.

It sounds like you want COBOL, which has:

MOVE A TO B

ADD A TO B GIVING C

Or, if you want it the other way around:

COMPUTE C = A + B

You can also say:

ADD A TO B

which puts the result in B. On the other hand:

MULTIPLY A BY B

puts the result in A!

Then there's:

DIVIDE A BY B

(or is it "DIVIDE A INTO B"?)

My point is that by trying to be more "natural" and follow
English language rules, rather than a concise and consistent
set of rules, COBOL ends up with something verbose
and inconsistent.

--
			Martin

STRL Reader in Software Engineering and Royal Society Industry Fellow
martin@gkc.org.uk  http://www.cse.dmu.ac.uk/~mward/  Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
Mirrors:  http://www.gkc.org.uk  and  http://www.gkc.org.uk/gkc

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

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

On Jun 7, 1:21 pm, Johann 'Myrkraverk' Oskarsson
<joh...@2ndquadrant.com> wrote:
> Joshua Cranmer <Pidgeo...@verizon.invalid> writes:
[snip]

>
>                                  <><><>
>
> Another point to make.  Why do we assign from right to left?  Is it in
> any way natural?  What's wrong with
>
>   a + b --> c                  "a plus b assigned to c"
>
> instead of
>
>   c <-- a + b                  "c becomes a + b?"
>
> The more I think about it, I believe the former construct is a bit more
> natural since we read from left to right.  However, I'd want to see or
> work on a non-trivial project in such a language to make up my mind.

But we already have languages that support

  a b + c ! ( stack based, for bang read store )

or

  ADD A TO B GIVING C.

I'll let you guess which languages support these constructs.

>
> For an Arabic programming language, all bets are off.

   ! c + b a

My first example reversed. The arity of the operators make it easy to
parse left to right too; "Store in c the sum of a and b". It would be
a trivial modification to a stack-based compiler to parse right to
left.

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

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

From: "Alex McDonald" <blog@rivadpm.com>
> On Jun 7, 1:21 pm, Johann 'Myrkraverk' Oskarsson
> <joh...@2ndquadrant.com> wrote:

>> Another point to make.  Why do we assign from right to left?  Is it in
>> any way natural?  What's wrong with
>>
>>   a + b --> c                  "a plus b assigned to c"
>>
>> instead of
>>
>>   c <-- a + b                  "c becomes a + b?"
>>
>> The more I think about it, I believe the former construct is a bit more
>> natural since we read from left to right.  However, I'd want to see or
>> work on a non-trivial project in such a language to make up my mind.

And what about languages that read from the top of the page to the bottom?

> But we already have languages that support
>
>  a b + c ! ( stack based, for bang read store )

Indeed, the earliest was Hamblin's GEORGE of 1957,
the above written as a b + (c)
where the parentheses indicated a store operation.

And his loop:

0
1, 10 rep (j)
   read
   (a)
   +
]
print

the meaning of which should be fairly clear as to sum 10 values
and to print that sum.
The square bracket is for end-of-loop.

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

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

Alex McDonald schrieb:

>> For an Arabic programming language, all bets are off.
>
>    ! c + b a
>
> My first example reversed. The arity of the operators make it easy to
> parse left to right too; "Store in c the sum of a and b". It would be
> a trivial modification to a stack-based compiler to parse right to
> left.

Note: even Arabic text is *stored* in low-to-high address order, so
that there is no need for reverse parsing. It's only the GUI that
flips the strings and their horizontal alignments.

DoDi

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

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

On 07.06.12 14:00, Joshua Cranmer wrote:
> 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.

There is a huge blind spot near ASCII, indeed.

Programmers might find it hard to tackle characters, so they
continue writing in---if I may put it that way---monkey mode:
one key press, one character. (Remember no-dead-keys?).
You can watch them work like an experimenter of behavioral
psychology will observe his animals: stimulus, response.
Engineering does not have to be smarter than that, does it?

After the fact, though, ASCII makes programmers' lives really hard,
because of the effects that the 7-bit table assumption will cause.
This assumption is fixed in the minds of programmers,
and is reinvigorated by defining every new programming language
on top of C's char together with a de facto 7-bit assumption.
A recipe for disaster, making software integration fail,
making languages hard to develop later. Character
set support in Ruby was proof of that; Python means a continuing
effort at getting libraries to work in the presence of the new (!)
str/unicode decisions for version 3.0 (!) of the language.
A similar road block seems to have appeared on the way to ATS v2.

If programming languages trigger adopting characters as
objects of proper data types just like they do with all
other objects, the quality of software will necessarily improve,
because the programmers handling characters will start
to work as carefully as they do with objects of types other
than char.

Maybe there is a pride issue in the way of accepting proper character
sets. Programmers being asked to learn how to use a computer's keyboard.
Embarrassing. The humiliation!  And all for turning  '<' '-' into that
fancy 'b'? No, for making you aware of plain characters in B%, b,, O,
rC4le play, etc. A language that offers a persuasive way of
making engineers type universal characters will have delivered
a killer feature.

-- Georg

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

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

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

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

Programmers don't seem to care to have keywords in their native language.
And many languages already make it possible to define aliases for keywords;
it just doesn't seem important.

>  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?

With Unicode, you have the situation that many identical glyphs have
different character codes, creating problems with different identifiers that
look exactly the same. And with no restrictions on what can appear, with
hundreds of obscure symbols, what could source code end up looking like?

And what is there beyond Unicode? Source code created as a bit-image - in
colour - being fed to a compiler? Good luck with that.

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

You can invent all the new symbols you like. But you've then created your
own language and your own tools. Then you swap computers with someone else
who's created their own set of symbols and a different layout...

But perhaps this is from the point of view of a language designer rather
than an individual programmer.

> 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?

This sounds more reasonable. But I suspect such interfaces already exist..

> [If you think English is wordy, you must not know any French, Spanish,
> or Italian, all of which are far wordier. ... -John]

Or German. Or Finnish. Practically any language based on our alphabet.
--
Bartc

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

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

"BartC" <bc@freeuk.com> writes:

> And many languages already make it possible to define aliases for keywords;

Which languages?  Robin mentioned PL/I.  Others?
[C and anything else with a preprocessor. -John]

And what about predefined libraries?  I imagine it's not too hard for a
non-English speaker to memorize the meaning of 50-or-so English
keywords, but what about thousands of names in the predefined
libraries?  Or third-party libraries?

> With Unicode, you have the situation that many identical glyphs have
> different character codes, creating problems with different identifiers that
> look exactly the same.

I'd solve that by allowing Unicode letters in identifiers, but require
the programmer to declare up front which ones they want to use (in a
project-wide configuration file of some sort).  Nobody wants to use
all of Unicode -- they just want to use the letters of one or two
natural languages, plus maybe a few symbols like a proper <= sign.

In comments, anything goes (allow all Unicode characters).

- Bob

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

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

Robert A Duff <bobduff@shell01.theworld.com> wrote:

(previous snip on English language keywords in programming.)

> And what about predefined libraries?  I imagine it's not too
> hard for a non-English speaker to memorize the meaning of
> 50-or-so English keywords, but what about thousands of names
> in the predefined libraries?  Or third-party libraries?

But many are only slightly related to any English words.

Well, maybe more now that languages allow for longer names, but many
of the older routines, from the Fortran 66 days, have almost no
mnemonic value at all. You just have to look them up (in any
language). The IMSL routines for example.

Some assemblers are more mnemonic than others. The IBM mainframe
assemblers like short mnemonics, A for add, L for load, so, yes,
the first letter of the English word, but not much more.
Only very rarely do assemblers use whole English words.

(Even more, the S/360 and successor hex opcodes for add, subtract,
multiply, and divide instructions usually end in A, B, C, and D,
respectively, such that add instructions end in A, and divide
end in D. Makes it a little easier to remember the opcodes.)

Even more, the IBM OS/360 and successor assemblers have OPSYN
so you can assign any names you want in place of the normal opcodes.
(And make it harder for readers who don't know your language.)

Well, with many assemblers you could write macros to expand
using other names, but OPSYN is more direct.

(snip)

> I'd solve that by allowing Unicode letters in identifiers, but require
> the programmer to declare up front which ones they want to use (in a
> project-wide configuration file of some sort).  Nobody wants to use
> all of Unicode -- they just want to use the letters of one or two
> natural languages, plus maybe a few symbols like a proper <= sign.

I believe that Java allows all unicode letters to start symbolic
names, and unicode letters and digits to continue them.

> In comments, anything goes (allow all Unicode characters).

Be careful with \u000a though.

-- glen

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

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

> Johann 'Myrkraverk' Oskarsson wrote

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

English is virtually the common world-wide language for computers,
in much the same way as English is the univeral language for pilots.

Nevertheless, some languages provide the means for users to
program in their own languages using latin alphabet.

For example, PL/I provides the means to change any or all
keywords to the user's native language.

For example, an Italian might write --

%declare (do, if, then) character;
%do = 'fare';
%if = 'se';
%then = 'poi';
and could then write a conditional as --
se A = B poi fare; ....

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

Russian omits the verb "is" and sometimes 'a' and 'the',
but French and Italian have similar constructions to English.
These three languages require agreement of adjectives with the
nouns that they qualify, that makes them more difficult to write
and to speak (because the pronunciation changes).
I don't agree that English is more verbose; however, English does not have
consistent rules for pronunciation or spelling ; some words with different spellings
are pronounced the same (e.g., to, too and two, etc).
[Although I'm happy to have discussions here about computer language design, I
draw the line at natural language design.  Anglophones can pronounce "Though the
tough cough and hiccough, plough through" and we like it that way. -John]

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

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

"robin" <robin51@dodo.com.au> writes:

> English is virtually the common world-wide language for computers, in
> much the same way as English is the univeral language for pilots.
>
> Nevertheless, some languages provide the means for users to program in
> their own languages using latin alphabet.

My point was that it may pay off to think outside the box when designing
a new programming language.  Or even extending an old one.

The two most common boxes are the ASCII character set and the English
language.

Can you make anything simpler if you add Latin grammar rules to your
language?

People naturally step out of the ASCII box and into Unicode.  Which is
just another box to think inside.  Step out of Unicode while you're at
it.

For these kinds of researches to be effective, they need to be done as a
team.  And here the academia is a natural venue.

I'm not going to repeat points already made elsewhere.
--
   Johann Oskarsson                http://www.2ndquadrant.com/    |[]
   PostgreSQL Development, 24x7 Support, Training and Services  --+--
                                                                  |
   Blog: http://my.opera.com/myrkraverk/blog/

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

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

Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> writes:

> Can you make anything simpler if you add Latin grammar rules to your
> language?

I would say the Lingua::Romana::Perligata [0] experiment supports answering
this one in the negative.

Try to guess the algorithm implemented here:

#! /usr/local/bin/perl -w
use Lingua::Romana::Perligata;
maximum inquementum tum biguttam egresso scribe.
meo maximo vestibulo perlegamentum da.
da duo tum maximum conscribementa meis listis.
dum listis decapitamentum damentum nexto
    fac sic
        nextum tum novumversum scribe egresso.
        lista sic hoc recidementum nextum cis vannementa da listis.
    cis.


[0] http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html

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

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

Johann 'Myrkraverk' Oskarsson <johann@2ndquadrant.com> writes:

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

I wouldn't say so.  Advanced type systems (bounded polymorphism and
linear types to name a few) have enetred the picture since.

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

As John mentioned, APL has been around for ages and used a lot of
non-ASCII symbols.  Algol was originally designed to use several
non-ASCII symbols that could be encoded in different ways depending on
the local symbol set.  ASCII was by no means a standard then --
FIELDATA and EBCDIC were common alternatives, so the choice was either
to limit the language to use the common subset (which was rather
small) or to use an ideal set of symbols and allow these to be
encoded.

ASCII certainly has the advantage of being easy to type using a
standard keyboard, but with touch screens it is now not so difficult
to have soft keyboard with various extensions.  But if I were to go
outside ASCII for a programming language, I would also use extended
layout: subscripts, superscripts and more.  Using a subset of HTML for
program layout would work fine: Programs can be displayed in any
browser and you can use HTML editors (and even ASCII editors) to edit
programs if you don't have access to a dedicated IDE.

	Torben

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

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

Torben Fgidius Mogensen <torbenm@diku.dk> wrote:

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

> I wouldn't say so.  Advanced type systems (bounded polymorphism and
> linear types to name a few) have enetred the picture since.

(snip about ASCII)

> As John mentioned, APL has been around for ages and used a lot of
> non-ASCII symbols.  Algol was originally designed to use several
> non-ASCII symbols that could be encoded in different ways depending on
> the local symbol set.  ASCII was by no means a standard then --
> FIELDATA and EBCDIC were common alternatives, so the choice was either
> to limit the language to use the common subset (which was rather
> small) or to use an ideal set of symbols and allow these to be
> encoded.

I thought ALGOL was older than both ASCII and EBCDIC.

EBCDIC, and its punched card coding, came with S/360 and the 029
keypunch. Before that, IBM had BCDIC (a six bit code) and the 026.

I (just barely) remember multipunching the codes needed for B5500
ALGOL on the 026. They put big charts on the wall (so you could
read them from across the room) showing the multipunch codes.

Was going from six bit codes to seven-bit ASCII a great awakening,
or a big mistake, not going directly to eight bits?

> ASCII certainly has the advantage of being easy to type using a
> standard keyboard, but with touch screens it is now not so difficult
> to have soft keyboard with various extensions.

It is convenient with a keyboard coded for ASCII characters!

There is the favorite quote, though I forget where it came from,
"The nice thing about standards is that we have so many to choose from."

> But if I were to go outside ASCII for a programming language, I
> would also use extended layout: subscripts, superscripts and more.
> Using a subset of HTML for program layout would work fine: Programs
> can be displayed in any browser and you can use HTML editors (and
> even ASCII editors) to edit programs if you don't have access to a
> dedicated IDE.

Java went to full Unicode, with \u escapes so you can enter codes
and edit on ASCII editors. I don't know if there are Unicode
editors yet, though.

-- glen

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

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

From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
> Torben Fgidius Mogensen <torbenm@diku.dk> wrote:
>
>>>>>Personally, I'd say there's been precious little new in programming
>>>>>languages since Simula gave us OOP in the late 1960s.
>
>> I wouldn't say so.  Advanced type systems (bounded polymorphism and
>> linear types to name a few) have enetred the picture since.
...
>> As John mentioned, APL has been around for ages and used a lot of
>> non-ASCII symbols.  Algol was originally designed to use several
>> non-ASCII symbols that could be encoded in different ways depending on
>> the local symbol set.  ASCII was by no means a standard then --
>> FIELDATA and EBCDIC were common alternatives, so the choice was either
>> to limit the language to use the common subset (which was rather
>> small) or to use an ideal set of symbols and allow these to be
>> encoded.
>
> I thought ALGOL was older than both ASCII and EBCDIC.

Algol 58 preceded both -- 1958.  See http://en.wikipedia.org/wiki/ALGOL

Next came ASCII in 1963.  See http://en.wikipedia.org/wiki/ASCII

Finally came EBCDIC in 1964, but probably didn't see actual use until
the S/360 in 1965(?).  See http://en.wikipedia.org/wiki/EBCDIC Before
that was a 3-zone code for punched card equipment, based on the first
three card rows, denoted Y, X and 0.

ASCII was freer to use a consistent assignment of characters,
with all the letters for a given case in consecutive binary positions.

On the other hand, EBCDIC was constrained by card encodings.
With the introduction of a 4-zone punch card code (Y, X, 0, 8),
many extra characters could be included, mostly punctuation.
For purposes of illustration only, the Y (or leading) row of the card
could contribute, say, 32 to the value of a character;
the X or second row could contribute , say, 48;
while the 0 or third row could contribute, say, 64.
A punching in rows 1 to 9 could contribute  the value of the digit.
Thus, alphabetic characters A to I would fall in the range 33 to 41;
J to R fall in the range 49 to 57, while S to Z fall in the range 66 to 73.
Thus, each of the rows Y, X and 0 could contribute a single bit
to the final value for the card column (but in practice,
it is more convenient to translate to two bits),
while rows 1 to 9 are converted to a 4-bit value
This arrangement simplified the electronics for the card reader.

> EBCDIC, and its punched card coding, came with S/360 and the 029
> keypunch. Before that, IBM had BCDIC (a six bit code) and the 026.
....
> Was going from six bit codes to seven-bit ASCII a great awakening,
> or a big mistake, not going directly to eight bits?

Back in the 1960s and 70s, not many electronic and non-electronic devices
could support more than 64 printable characters, so ASCII was adequate
for many years to come.  Those who wanted to could
use upper and lower case with such devices as the ASR 38, Memorex 1240, etc,
and Friden flexowriter (a slightly modified version was available for Algol).

The ubiquitous ASR 33 (mechanical and electronic forms)
used an 8-bit code.  The 8th bit could be left blank or could be
used for parity, so 7 active bits proved to be sufficient for the times.
More than 7 would have rendered parity checking impossible,
and computer paper tape readers typically checked parity.

>> ASCII certainly has the advantage of being easy to type using a
>> standard keyboard,

That's because the keyboard was designed for ASCII.

As for Algol 58 (and then Algol 60), it was designed as a
publication language, for which it filled the bill admirably.
Implementing it on a computer was, however, compromised
though the use of many characters not available on I/O
equipment.  The lack of a means of back-spacing on most
preparation equipment meant that alternatives such as reserved words,
and apostrophised keywords were sought as a substitute for underlining,
upper-case everything, and of course, I/O statements differed
from installation to installation.
But, as they say, it's the thought that counts!

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

#482

All,

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

Interesting post that spurred me into writing something related:
http://shape-of-code.coding-guidelines.com/2012/03/08/the-fatal-programming-language-research-mistake/

> [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]

I thought that we had now progressed on to whether indentation should be
part of the language syntax ;-)

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

#483

On Wed, 07 Mar 2012 13:52:47 +0000, Rui Maciel <rui.maciel@gmail.com>
wrote:

>... there appears to be no correlation
>between the success of a programming language and its emergence in the form
>of someone's 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 aren't that important for mass adoption of
>programming languages.

Theoretical nicety and $3 will get you a cup of coffee.  What matters
to adoption is utility and timing.  Something that comes along at the
right time, works well enough and fills a void for enough people will
succeed.

A lot of thought went into clean design for Scheme, ML and Haskell ...
but they have few adherents.  Common Lisp, though it certainly has
theoretical underpinnings, is a mishmash of features borrowed from
previous languages - other Lisps, Algol, and even from Scheme.  Common
Lisp has more users than Scheme, ML and Haskell combined.

In a number of ways Pascal was more powerfully expressive than C.  But
Pascal had initial misfeatures that made it harder to use effectively
and, because it was envisioned originally for teaching, it omitted
some features that limited the scope of programs that could be
written.  Subsequent extensions corrected many of the problems, and
new languages came along based upon Pascal that were superior to C in
nearly every way ... but too many people already had decided that C
was good enough.


>one striking commonality in all modern programming languages, especially
>the popular ones, is how little innovation there is in them!

Innovation in what sense?

It's true that no shocking new programming paradigm has come along
recently.  That is to be expected.  Despite some cultural differences,
humans all are wired similarly and tend to think about problems in
(combinations of) a relatively small number of ways.  The existing
paradigms already address ways in which humans are known to be capable
of thinking (and even some ways they aren't - e.g., ANN).

A language that forces an unnatural way of thinking on the programmer
is not likely to be adopted.  Many people have a hard time adjusting
to thinking in different ways.  Witness that nearly all of the popular
languages are serially procedural.  That implies heavily that the
majority of people think - or at least prefer to think - in that way.


>- 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?

More expressive static type systems and better type inferencing would
be appreciated.

Something still is needed to better take advantage of parallelism.
Serial processing speeds ares not expected to improve in the near
future, and CSP (ala Hoare) at its current macro level of use has
reached it's limits.  It's extremely difficult for a programmer to
identify all, or even most, of the parallelism potential in an
application and take advantage of it using existing CSP mechanisms.

There already are programming paradigms that better expose
parallelism, but we are lacking implementations that take advantage of
them.  And some paradigms are difficult to use directly: e.g.,
dataflow, like continuation passing, often requires thinking about
inverted execution paths.


> Or have we reached the asymptotic plateau of
>innovation in this area?

Programming language design is not a single area - it encompasses
politics, logic, semantics, linguistics, mathematics, and even physics
because hardware ultimately decides what can be programmed and how.


>So, what are your views on this subject?

CREATE VIEW mine AS
	SELECT opinion FROM me;


>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]

I'd have to disagree with that.  Declarative programming, though it
existed earlier (just as OO concepts existed prior to Simula), arose
as a paradigm in the 70's popularized by the introduction of Prolog.

As always, your semicolon placement may vary.
George

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

#484

Rui Maciel <rui.maciel@gmail.com> writes:

> - And here's the first itchy point: there appears to be no correlation
> between the success of a programming language and its emergence in the form
> of someone's 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 aren't that important for mass adoption of
> programming languages.

As a non-academic, I agree.  None of those things matter very much to me
when it comes to actually getting stuff done.  They are not bad things
to have, but they are not the things that matter.


> - 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?

As others have mentioned, there may be some good ideas to come in the
area of safer and more efficient parallel programming.  I like the CSP
model, but perhaps there is something better.  I personally think the
model of threads, mutexes and condition variables has so far proven too
difficult to use correctly for most programmers.  That goes double for
the atomic operations and barrier model.  And functional and dataflow
programming languages do not appear to have gotten much adoption in
practice.

I also think there is more room for thought about programming in the
large.  Many software shops these days are huge, producing programs that
are far too large for anybody to keep in their heads.  As a side-effect,
many programmers spent a lot of time performing maintenance of various
sorts.  What can languages do to help?  Refactoring is just the most
obvious example in this space, and even there it is clear that some
languages support refactoring far better than others.  Other areas
related to language are speed of development, dependency management,
ease of debugging, modularity, ease of performance analysis, no doubt
many more.

Ian

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

#485

On Thu, Mar 8, 2012 at 8:02 PM, Ian Lance Taylor <ian@airs.com> wrote:
> Rui Maciel <rui.maciel@gmail.com> writes:
>
>> - And here's the first itchy point: there appears to be no correlation
>> between the success of a programming language and its emergence in the
form
>> of someone's 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 aren't that important for mass adoption of
>> programming languages.
>
> As a non-academic, I agree.  None of those things matter very much to me
> when it comes to actually getting stuff done.  They are not bad things
> to have, but they are not the things that matter.

Reminds me of an old linguist joke:

> A gentleman wanders around the campus of a college looking
> for the library. He approaches a student and asked, "Excuse
> me young man. Would you be good enough and tell me where
> the library is at?"
>
> The student, in a very arrogant and belittling tone, replied,
> "I sorry, sir, but at this school, we are taught never to end
> a sentence with a preposition!"
>
> The gentleman smiled, and in a very apologetic tone replied,
> "I beg your pardon. Please allow me to rephrase my question.
> Would you be good enough to tell me where the
> library is at, a@hole?"

This summarizes my empirical experiences well. Programming languages
appear to grow organically, as if they were species. There are many
dialects, from many tribes. Sometimes, a new language feature is
created out of utility. If that feature is very useful, it spreads to
different dialects. Later, theorists study the phenomena and define it
formally. Sometimes, out of utility, a language feature is created by
a tribe. Other tribes may not find this feature particularly useful.
It becomes a regional colloquialism or dies off.

Cameron

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.compilers

csiph-web