[TUHS] Why Pascal is Not My Favorite Programming Language - Unearthed!

[Bakul Shah]

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