The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!
Date: Thu, 31 Aug 2017 19:27:15 -0700	[thread overview]
Message-ID: <20170901022715.GL448@mcvoy.com> (raw)
In-Reply-To: <6D07E768-A4CA-42F5-9D32-E8ECAAB4CB96@bitblocks.com>

No offense intended but I pretty much dealt with all of this in L.
little-lang.org

I'll freely admit it is not perfect but it certainly touches on your
comments and would not be hard to bring into C.

On Thu, Aug 31, 2017 at 07:22:10PM -0700, Bakul Shah wrote:
> 
> > On Aug 31, 2017, at 6:26 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote:
> >> 
> >>> On Aug 31, 2017, at 2:46 PM, Larry McVoy <lm at mcvoy.com> wrote:
> >>> 
> >>> On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote:
> >>>> I look to the likes of go and rust to get us back on track.  C is a pretty good assembly language.
> >>> 
> >>> So what chaps my grumpy old hide is why the heck do a whole new language
> >>> when you have one that is pretty good?  Suppose we took C and added a
> >>> dialect via options:
> >>> 
> >>> 	--no-ptrs	// use arrays and indices, you get bounds checking
> >>> 	--strings	// system managed memory for strings, like tcl
> >>> 	--perlisms	// if (buf =~ /re/) and unless (it_worked())
> >> 
> >> Such a language would stop being C.
> > 
> > Indeed.  But it builds on C.
> > 
> >> In Go you can use slices instead of arrays (but slices are only one dimensional).
> >> Ptrs are relatively safe as memory is garbage collected so e.g. a function can
> >> return &local_variable. No perlism.
> >> 
> >> Go provides other features which are quite useful: concurrency, channels,
> >> interfaces, packages.
> >> 
> >> People who like C tend to like Go. But Go is not low-level enough. No one
> >> is writing a kernel in it! Or doing bare metal programming. AFAIK.
> > 
> > Exactly.
> > 
> >>> etc.  Why create an entirely new language, new syntax, new linkage, etc,
> >>> instead of fixing C's shortcomings?
> >> 
> >> C has too many problems. If you try fixing them, none of the "dusty decks"
> >> would run on such a compiler + the new language would be severely
> >> hampered in its evolution due to its C legacy.
> > 
> > So I'd need to understand more to believe that claim.  And for the record,
> > what I'm going for is a new C that is still C enough to be useful but
> > fixes the problems enough to be a new language.  Someone asked about
> > C++ and D, nope.  Too far from C.  I just want a C that fixes enough
> > of the problems that it is more acceptable to modern programmers but
> > is still C.  Not sure if I'm explaining that well enough.
> 
> See below. I think it would be not easy to build a simpler language
> that is consistent and regular. I just touched on a couple of things
> but there would be many more such small decisions....
> 
> 1. Ptrs. If you remove them completely, functions can become
>    pure and can not change anything. Most likely you'd end up
>    adding "ref" parameter, which would be sorta like Pascal's
>    var parameters.
> 
>        int f(var int x) {
>                 x++;
>                 return x
>        }
> 
>         ...
>         int z = 1;
>         int y = f(z);   // y should be 2
>         int x = f(z);   // x should be 3
> 
>    The benefit is that now you can not clobber the ptr but
>    otherwise the same result.
> 
>    Do you allow declaring refs? You should for consistency.
> 
>         int x1;
>         ref int x2 = x1;
> 
>    But if you allow this, either this assignment behaves
>    differently from a ref int parameter or it would crash
>    since x2 doesn't really point anywhere on initialization.
>    So now you will be tempted to say
> 
>         ref int x2 = ref x1;
> 
>    This is almost exactly like
> 
>         int *x2 = &x1;
> 
>    A bit ugly.  IIRC Algol68 had something similar and well
>    defined rules for how multi level refs were handled.
> 
> 2. Passing Arrays. Now you need a way to pass subarrays.
> 
>         int z[] = {1,2,3,4};
>         int g(int x[]) {
>             ...
>         }
>         ...
>         int x = g(z[3:5]);      // g.x[0] = z[3]; g.x[1] = z[4].
> 
>    Now you need a way to iterate through the array in g.
> 
>         int g(int x[]) int {
>             int sum = 0;
>             for (int i = 0; i < len(x); i++) sum += x[i];
>             return sum;
>         }
> 
>    But what happens if in g you change x[i]? Does z change?
>    If you don't allow this, x[] becomes a constant but a
>    scalar variable can be changed. So this is inconsistent.
> 
>    If you allow this, int x[] almost acts like var int x[]!
>    For consistency with scalars you should copy z[3:5] but
>    that can be expensive for large arrays. So now you will be
>    tempted to use const (now a ref can be impllicitly passed
>    since array won't be written over).
> 
>    Then there is the issue of multidimensional arrays.
> 
>         int z[4][5];
>         int h(int x[][]) {
>             ...
>         }
>         int w = g(z[2:4][1:3]);
> 
>    If you are fixing arrays, you may as well do them right
>    so that fortran code can be easily ported.  So what about
> 
>         int h(int x[][]) {
>                 int s = g(x[1][]);
>         }
> 
>    Here we're passing a column of z as a vector to g.
>    You'd end up with a illife vector or something! But
>    if you do this, vector access can slow down...

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


  reply	other threads:[~2017-09-01  2:27 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-30 12:34 arnold
2017-08-30 14:13 ` Eric Wayte
2017-08-30 14:30 ` Michael Kjörling
2017-08-30 14:43   ` Eric Wayte
2017-08-30 17:10 ` Mutiny 
2017-08-30 22:33 ` Michael Parson
2017-08-31  0:55   ` Nemo
2017-08-31 13:29     ` arnold
2017-08-31 18:24       ` Nemo
2017-09-03  0:56         ` Dave Horsfall
2017-09-03 12:07           ` arnold
2017-09-03 22:03             ` Dave Horsfall
2017-09-04 12:12               ` Steffen Nurpmeso
2017-08-31  1:13 ` Bakul Shah
2017-08-31 14:48   ` Larry McVoy
2017-08-31 15:26     ` Eric Wayte
2017-08-31 16:12       ` Warner Losh
2017-08-31 17:51         ` Larry McVoy
2017-08-31 18:40           ` Clem Cole
2017-08-31 19:25             ` Steffen Nurpmeso
2017-09-01  1:57               ` Nemo
2017-09-01 14:17                 ` Steffen Nurpmeso
2017-09-01 14:28                   ` Arthur Krewat
2017-09-01 14:48                     ` William Cheswick
2017-09-01 15:15                       ` Clem Cole
2017-09-01 15:47                       ` Arthur Krewat
2017-09-01 16:21                       ` Nevin Liber
2017-09-01 16:34                       ` Dan Cross
2017-09-02  0:24                         ` Dave Horsfall
2017-08-31 19:47             ` Toby Thain
2017-08-31 20:37               ` William Cheswick
2017-08-31 20:51                 ` Clem Cole
2017-09-01  0:52                   ` Bakul Shah
2017-08-31 21:46                 ` Larry McVoy
2017-08-31 21:59                   ` Arthur Krewat
2017-08-31 22:08                     ` Larry McVoy
2017-09-01  1:11                       ` Steve Johnson
2017-09-01  0:57                   ` David Arnold
2017-09-01  1:22                   ` Bakul Shah
2017-09-01  1:26                     ` Larry McVoy
2017-09-01  1:51                       ` Kurt H Maier
2017-09-01  2:22                       ` Bakul Shah
2017-09-01  2:27                         ` Larry McVoy [this message]
2017-09-01  2:58                           ` Bakul Shah
2017-09-01  3:12                       ` Dan Cross
2017-09-01  2:51                     ` Dan Cross
2017-08-31 20:37               ` Clem Cole
2017-08-31 21:26                 ` Toby Thain
2017-09-01  2:38               ` Dan Cross
2017-09-01  3:59                 ` Toby Thain
2017-09-01 15:57                   ` Dan Cross
2017-09-01 16:08                     ` Toby Thain
2017-09-01 18:15                       ` [TUHS] Future Languages (was Pascal not Favorite...) Steve Johnson
2017-09-01 18:43                         ` ron minnich
2017-09-01 23:33                           ` Chris Torek
2017-09-04 20:55                             ` ron minnich
2017-09-01 20:42                         ` Clem Cole
2017-09-04 20:44                         ` Bakul Shah
2017-09-01 13:46                 ` [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed! Clem Cole
2017-09-01 14:43                 ` Toby Thain
2017-09-01 15:14                   ` Clem Cole
2017-09-01 16:22                   ` Dan Cross
2017-09-01 19:07                     ` Toby Thain
2017-09-02 13:25                       ` Dan Cross
2017-09-02 15:00                 ` Toby Thain
2017-09-02 15:16 Diomidis Spinellis
2017-09-02 19:53 ` Toby Thain
2017-09-03 14:48 Norman Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170901022715.GL448@mcvoy.com \
    --to=lm@mcvoy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).