Interesting, my paper copy is dated July 18, 1981 on both the title page and after the abstract. On Wed, Aug 30, 2017 at 10:30 AM, Michael Kjörling <michael(a)kjorling.se> wrote: -- Eric Wayte

Nemo <cym224(a)gmail.com> wrote: You should probably use refer -e to get the references at the end. The original PS is in the http://www.skeeve.com/cstr.tar.gz tar ball, for comparison purposes. :-) I will eventually set up a github repo with this doc and I hope instructions for formatting with groff. Thanks, Arnold

On Thu, 31 Aug 2017, Nemo wrote: Err, because CR/LF was the line terminator? -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

On Sun, 3 Sep 2017, arnold(a)skeeve.com wrote: Then it must've passed through an MS/DOS gateway :-) -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

In the mid 80's when I took Programming II as part of my CS degree, I used every Pascal compiler I could get my hands on: Waterloo Pascal on VM/CMS (mainframe), Turbo Pascal, UCSC p-System on an Apple II, and Kyan Pascal on my Atari 800XL. Fun times! On Thu, Aug 31, 2017 at 10:48 AM, Larry McVoy <lm(a)mcvoy.com> wrote: -- Eric Wayte

+1 on everything he said. Especially the bug chasing. As a leader, a lot of what I've done has been to push back on "clever". On Thu, Aug 31, 2017 at 10:12:43AM -0600, Warner Losh wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

Clem Cole <clemc(a)ccc.com> wrote: |Without reliving the Pascal/C war of the day, I have to admit that \ |I too loved Brian’s piece when we wrote it and love it still.   But \ |you have to |understand the context.    | |>>  If Unix was written in Pascal I would've happily continued using Pascal! | |>Amusing in the context of Brian's piece, which essentially says if Unix |>could have been written in Pascal, then Pascal wouldn't have been Pascal. | |Doug amen. | |There really are a few pieces of information that I think are lost \ |from history.    Pascal was and is still as difficult to match as a \ |teaching |language.   Brian says exactly that in is piece – it is like a ‘Piper \ |Cub.’   I still use it for just that when I teach scouts, nieces, nephews \ |or |anyone else that asks me, where to start.  Today’s "Free Pascal" system \ |is pretty hard to beat - runs on anything and "just works." So, please, let me disagree absolutely. I had only experience of some Microsoft Basic in the 80s before i had to (should) learn some Pascal (i dropped that qualification), and i still hear myself asking the teacher "What? A language without goto?" Even with closures or inner functions and/or whatever may exist i think it is a grace that the simplicity of goto: can also be used in a higher level language. Despite anything else, my brain also works that way. It also did not like sitting still in school at 10 o'clock in the morning or in the afternoon, of course, but if it is like that? That became better over time, but it was not like that in school. Now the following is perl(1) which warns since some version on goto: into a loop, but i would not want to teach young human beings such in school, it is weird enough that people lseek(2) an O_APPEND descriptor to SEEK_END because they became socialized with stdio, in my humble opinion. my $ogoditisanewperl = 0; if(defined($nl = $self->begin_line)){ $self->begin_line(undef); $self->seen_endl(1); $ogoditisanewperl = 1 #goto jumpin; } while($ogoditisanewperl || ($nl = readline $self->infh)){ if(!$ogoditisanewperl){ ++${$self->__lineno}; $self->seen_endl($nl =~ s/(.*?)\s+$/$1/) } $ogoditisanewperl = 0; #jumpin: --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Nemo <cym224(a)gmail.com> wrote: |Shades of Myfol vs. Yourtran! | |On 31/08/2017, Steffen Nurpmeso <steffen(a)sdaoden.eu> wrote (in part): |> and i still hear |> myself asking the teacher "What? A language without goto?" | |Pascal has always had goto. (One of Wirth's pascal compilers even |jumped from within one function to a label inside another function!) | |The construct was removed in Modula. (As Parnas has said, the problem |is not having a comefrom to go with the goto.) No, no, not the Pascal that we had to use there. Definitely not. Anyway, that is my rememberance, and i had to work with this for a few months, and it (the GUI) surely had that command index page, too. I surely have looked for goto. It was running under DOS. (It was a German school, no University. Thus.) Hm. Maybe a castrated educational version? Could that be? Has such thing ever existed? Possibly even with the possibility for the teacher to activate an extended command set for the progressed learners?? Interesting. Sorry for the rest. I am coming from the holistic side anyway so that purely intdoctrinating education without cultivating heart and soul "i" (thus, say, since maybe 15 or 16, or 17) never liked. I recall Smalltalk being proposed for education, but regardless of the language i think the most important part is that the children becomes curious and tries to discover and develop. I personally do not think that automatisms are good at all. If you cook, you have to clean the kitchen. If you tinker with your car or motorcycle you have to clean your tools at least. If you want to reap you have to sow. If you want to use dynamic memory you have to release it. Some things have to be let. That is also something important to be learned. You can say bees are dying and that is good, let's just kill the rest and anything else that interferes, because the computer managed bee-drones that are being developed will not need no neutral zones at all, so a field with genetically manipulated seeds and massive crop eh protection can be layed out right beside an organic farming one. They exactly follow the desired plan. So to say. Or you let, and possibly even create living willow fences surrounding them and the one or the other accompanying tree, too. Like Prince Charles promotes since at least the 1970s, if that remark is allowed. To me the latter sounds more healthy, also mentally. Admittedly all that needs fresh water, an emerging of the increasing problems. So nice and tiny, controllable and fully understood little objects are surely something good, letting them play together is like bouncing balls in the circus, but omnipotence dreamings should be targeted in the educational process also in the western world, me thinks. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

I think we have 30 years’ experience that clearly shows that dangerous languages will be misused in critical areas, even if most of us are very careful. Marcus Ranum once wrote a one-page version of inetd that he thought was secure. He was and is as committed to security as anyone, and had long experience writing software important to the early Internet. Steve Bellovin found a security hole in that one-page program. I am convinced that a safe language with very tiny holes allowing access to dangerous stuff (like memory management in the kernel) is simply safer. Clearly, we are no where near that right now.

On 9/1/2017 10:48 AM, William Cheswick wrote: I had to chuckle at the above. This was back in the day when I could telnet into almost any TOPS-20 system using user account ANONYMOUS and a password of FTP (or something similar depending on the system). It wasn't more than a few minutes before I found an unprotected file somewhere that could be altered and lay in wait for someone to run it. TOPS-10 systems were even easier. VMS wasn't a big deal either. Even the UNIX systems at the time were never really secure. I was the ARPANET's and early Internet's worst nightmare. TELENET was an even better source of stuff to look at. Thankfully, I was not malicious nor profit-driven. I still posit that C in the hands of the right people is not prone to buffer overflows any more than some library issue in C++ or higher languages. Higher languages that put up safeguards are only as good as the programmers who write the compiler/interpreter. Because deep down, the libraries themselves, or the kernel itself is written in something without hand-guards to keep you from cutting your fingers off. It's all machine code in the end with, for example, no limits on pointers except those that are constructed by more programmers or the memory protections built into the processor (i.e. DEP). In other words, by using a "safe" language you are just putting your security in the hands of other people who may or may not be as concerned as you are about it. You can only put a certain amount of bubble-wrap around a razor blade. In the end, there's still a razor blade under all those layers.

On Fri, Sep 1, 2017 at 10:48 AM, William Cheswick <ches(a)cheswick.com> wrote: I think I would amend this to say something along the lines of, "we have 40+ years of experience clearly showing that dangerous languages cannot be used safely in critical areas without a disproportionate amount of care and effort, despite the best efforts and skill of our best programmers." Marcus Ranum once wrote a one-page version of inetd that he thought was Moreover, as Steve said, what we consider "programming" these days is different than it was even 20 years ago: the programs we write are largely glue tying together a dizzying array of complicated and powerful libraries. There was a time that whenever I wanted a linked list in C, well, I'd just add a 'next' pointer to a struct; if I wanted a tree, I'd add 'left' and 'right' pointers. For the *vast* majority of programmers, those days are gone but our languages don't really reflect that. - Dan C.

On 2017-08-31 2:40 PM, Clem Cole wrote: Professor Knuth seemed to manage OK, writing TeX and METAFONT in Pascal (using his literate programming toolset, but that did not extend the language much). I suppose Apple's Pascal and Object Pascal -- used for Lisa and Macintosh applications and systems software -- comes under the "so people fixed it" category? --Toby

On Thu, Aug 31, 2017 at 4:37 PM, William Cheswick <ches(a)cheswick.com> wrote: ​ditto, Pascal and Mod-II and Mod-III were pretty slick. They were a little wordy compared to C, but I admit the programs we wrote in them "just worked" and I can not think any security issues in any that we wrote. ​+1 But Ches, that leaves the open question of what to teach? My daughter loves it and that's what college taught her, but I cringe when I look at what she and her peeps do with Python. To me that's more like shell scripting. Maybe its my inner curmudgeon showing. I have not seen anything like Clancy's "Oh Pascal" book in the key of Go, much less Brinch Hansen's "Java for Everyone" ​which I still think are two of the best teaching text out there.

On Thu, Aug 31, 2017 at 04:37:17PM -0400, William Cheswick wrote: 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()) etc. Why create an entirely new language, new syntax, new linkage, etc, instead of fixing C's shortcomings?

I sorta did, though it could use some polish: http://www.little-lang.org/ example that I use to do my photo layout: http://mcvoy.com/lm/photos.l which does stuff like: http://www.mcvoy.com/lm/hockey-portraits/ -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

Like C++? Or D? d

On Thu, Aug 31, 2017 at 06:22:41PM -0700, Bakul Shah wrote: Indeed. But it builds on C. Exactly. 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. Yep. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

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

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 Thu, Aug 31, 2017 at 9:22 PM, Bakul Shah &lt;bakul(a)bitblocks.com&gt; wrote: There are a few different projects: at least two under current investigation at MIT; an earlier project out of Spain using a modified version of the language. I'd be surprised if there were not others. - Dan C.

On 2017-08-31 4:37 PM, Clem Cole wrote: Those were mechanical translations from the Pascal. You're right though, that this could improve things when the C compilers were better than the Pascal compilers or where only a C compiler was available. (I ported TeX in this way a couple of times and did a lot of hacking on a Pascal-to-C translator.) --T

On 2017-08-31 10:38 PM, Dan Cross wrote: My point was that these are very much "real world" programs in a rather vanilla Pascal. (And if you want to bring SAIL into it as another substrate for "real world" programs, we might learn something from contrasting it with Pascal and C. I don't remember anything about it.) --Toby

On 2017-09-01 11:57 AM, Dan Cross wrote: I think *everything* we do is "in spite of" the language we're using. :) We will never reach a point where programming language evolution stops, imho. --T

On Fri, Sep 1, 2017 at 11:16 AM Steve Johnson &lt;scj(a)yaccman.com&gt; wrote: What I have found interesting, in the several Go projects I've been on, is how quickly people walk away from the CSP-like ideas (goroutines and chans) to all the old school shared memory techniques, mutexs, linked lists, and such, based on microbenchmarks. ron

On Fri, Sep 1, 2017 at 4:33 PM Chris Torek &lt;torek(a)torek.net&gt; wrote: thanks. Great article. He does hit on many of the things I've found annoying. It leads me to wonder: maybe Go 2 should fix this stuff. And now I stop, as I am totally off the topic...

I think the problem is much wider than just programming languages. Most of our PLs, programs & tools are basically for single machine things. Our compilers, linkers, debuggers can only handle this case well. With a few exceptions. This is not a good fit for a major class of applications today: service software. This is typically composed of a number of loosely coupled programs running on a set of networked machines. Managing this is done in a very ad-hoc & complicated manner (e.g. kubernetes). A service is implemented with essentially a distributed program but our tools don’t make it easy to compose or debug such programs. Things like dockers, containers, jails are complicated ways of dealing with problems we run into re: security, fault isolation, resiliency, scalability etc. At the other extreme, dealing with GPUs or specialized processors with zillion cores, each with a small amount of memory etc. is also painful and ad-hoc. In this context even if you prove a single component to be bug free, how can you have confidence in the whole system? It is well-nigh impossible to test all the gazillion ways a system can fail on a small scale or large (e.g. a java based component ran out of file descriptor or a packet gets misrouted or firewall rules are not quite right). Moving to something like Cloud would be an improvement over docker & VMs but that still leaves open the composition aspect. Now likely there isn't a single silver bullet for all of this but our present systems are far more complicated than they need to be. > "Toby Thain: We will never reach a point where programming language evolution stops, imho." > > > I'm currently working for a hardware company (Wave Computing). We are building a chip with 16K 8-bit processors on it, and have plans to build systems with up to 1/4 million processors from these chips. > > Nevertheless, most programs today are still written pretty much like they were 25 years ago. And they are, for the most part, based on threads where the programming task is to set out a number of steps: do this, do that, do something else, test this and if true do this, ... A single serial thread. Things like multicore CPUs are a desperate attempt to preserve this model while the hardware world has blown past us. > > Recall that parallelism is the natural state of hardware. It takes effort to make things work sequentially. In the old days, when hardware and software used pretty much the same model, many if not most of the hardware innovations came from first being done in software, and then moved into hardware -- index registers, floating point, caches, etc. etc. That process has effectively stopped. The single thread model simply no longer fits the sweet spot of today's hardware technology. > > Just to underscore how far hardware has advanced: If cars had become as much cheaper and faster as computers from 1970 to today, we could buy 1000 Tesla Model S's for a penny and they would go 0-60,000 mph! A petabyte of data, if punched onto punch cards, would make a card deck whose height would be 6 times the distance to the moon. If the recent estimate of the number of bytes of data produced by the human race every day (2.5 quintillion bytes) is correct, when punched up that card deck would be 9 times the distance to the sun. > > I'm not saying that there isn't a place for languages like GO and Python. Most people will continue to think serially and design things that way. But when it comes to implementing these designs, the current "systems" languages are left at the starting gate. In the same way that we invented abstraction methods like functions and processes for the old computers, we need to invent newer abstraction methods that go far beyond co-routines and threads and message passing. If we get bogged down in telling tens of thousands of processors "do this, do that" we will perish long before our program works. Of particular relevance is the role that abstractions play in debugging --they partition the job into pieces with known interfaces and behavior that can be tested in isolation before being assembled into complete systems. > > Yes, I have some ideas (and not much time to work on them...) but, even if I had a perfect solution available today, I suspect it would take decades before it caught on. In order to accept a solution, you first have to believe there is a problem... > > Steve > > > > ----- Original Message ----- > From: "Toby Thain" &lt;toby(a)telegraphics.com.au&gt; > > > We will never reach a point where programming language evolution stops, > imho. > > --T >

On 2017-08-31 10:38 PM, Dan Cross wrote: I don't think any of the above is in doubt. (Tyranny is not the word I would use. A more modern viewpoint would include topics like parametric polymorphism, typeclasses and so on.) It seems inconceivable to me that there are "ambitious parts" of TeX and METAFONT that Professor Knuth had to omit because he was using Pascal. Knuth has shown himself in various ways (including MIX, but also his literate programs in Pascal and C) to prefer programming at low levels (by modern standards) but his code amply shows that Pascal barely presented any impediment to doing so -- though he now uses literate C. Of course his programs would look different in, say, Haskell or Ocaml. I have not compared the codebases but wouldn't one expect that the final production TeX rewrite is *more* ambitious than the early SAIL version? (By the time I began using/porting TeX in the 1980s, the older version was completely obsolete.) I honestly don't know what limitations you mean. If you mean "different style of expression," sure. (Maybe if SAIL had lexically scoped lambda closures, there'd be a difference worth talking about...) I'm not sure if the Apple compiler used circa 1983 was *Object* Pascal but it was certainly extended with many intrinsics, casts, and pointer operations, bringing it essentially into parity with C for systems and application programming. --Toby

On Fri, Sep 1, 2017 at 10:43 AM, Toby Thain &lt;toby(a)telegraphics.com.au&gt; wrote: The specific use of the word "tyranny" was meant to be tongue-in-cheek. Apologies if it did not come across. But he wasn't using Pascal. The point was to wonder whether TeX and METAFONT would be different programs if he were. Clem seemed to imply that he thought that was unlikely, based on his previous use of SAIL. [snip] I don't know, but that's besides the point: the question was more about how the initial programming language shaped the design of the program. Specifically, had Knuth *started* in Pascal instead of SAIL, would TeX have been different? To put it another way, to what extent was he constrained, freed, or otherwise influenced by his medium? Formally speaking, Pascal is no more limited than any other Turing-complete language. But there's a difference between *formal* expressiveness and *informal* expressiveness. Some languages require proportionally more effort to produce the same program than others. I'm told that sed is Turing-complete; I'd sure hate to write TeX in it. The specific "limitations" I'm referring to are mostly covered in the BLTR #100; things like array length being part of the array object's type; lack of compile-time initializers, statics, etc. As an illustrative example, consider the case of a simple dispatch loop where I want to do some work based on the entry of some string key. In C, one might write something like this: typedef struct Cmd Cmd; struct Cmd { const char *cmd; int (*thunk)(void); }; int acmd(void); int bcmd(void); // Etc.... Cmd cmds[] = { {"a", acmd}, {"b", bcmd}, // ...etc... }; #define nelem(A) (sizeof(A)/sizeof((A)[0])) int dispatch(const char *cmd) { for (size_t k = 0; k < nelem(cmds); k++) { if (strcmp(cmds[k].cmd, cmd) == 0) return cmds[k].thunk(); } return -1; } But how would one write this in Pascal? For a completely unrelated task, I actually tried to write something like this in Pascal a few weeks ago and found the lack of compile-time initializers to be an impediment. It struck me that I could create a record type of some kind or another and dynamically create a dispatch table via an initialization procedure (say, building up a linked list or create an array of pointers to functions), but it struck me that it was possibly more work than just avoiding the table-driven approach and having a bunch of hard-coded test cases inside of a loop. Etc. This confuses me; Apple Pascal and Object Pascal are distinct but related languages. I specifically referred to Object Pascal, Delphi and Free Pascal but not Apple Pascal. It strikes me in re-reading what I wrote earlier that my comments were a bit of a non-sequitur. My bad. - Dan C.

On Fri, Sep 1, 2017 at 3:07 PM, Toby Thain &lt;toby(a)telegraphics.com.au&gt; wrote: But by then the major design decisions would have been made. Was TeX after that rewrite an appreciably different language? I'll shoot him an email. I'm well aware of that, which is why I specifically mentioned lexical Hmm, it seems there are a number of more fundamental issues with the language. I listed a number, mostly cribbed from Kernighan's paper and my own experience. - Dan C.