From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!
Date: Thu, 31 Aug 2017 19:58:16 -0700 [thread overview]
Message-ID: <9455B90D-9C12-4FFB-A782-E7335749E3A7@bitblocks.com> (raw)
In-Reply-To: <20170901022715.GL448@mcvoy.com>
I did a quick read of the language spec but I didn't see a rationale or
nit picky details.... Would have to study it more but I'm not convinced
it is better..... I believe Go has pretty much everything L has (+ I like
its support for concurrency).
Stroustrup's C with classes did seem better but then it became C++.
> On Aug 31, 2017, at 7:27 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
> 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
next prev parent reply other threads:[~2017-09-01 2:58 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
2017-09-01 2:58 ` Bakul Shah [this message]
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=9455B90D-9C12-4FFB-A782-E7335749E3A7@bitblocks.com \
--to=bakul@bitblocks.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).