News for 2019-03-20

[Scott Franco]

Hi,

Thought I would put out a news roundup at the end of the quarter. Paid work has taken precidence, and thus work on P6 has slowed down I bit. But I am sure it will go to functional (full up) testing this year.

1. The Pascaline standard document was updated for version 0.4. This is a big revision since, as we are coming to the end of the P6 functional bringup, it represents what I believe is the final form of the language. It contains a lot of detail on Pascaline, like common objects, that I held back from putting in the spec until I worked out further details. Common objects is a big, big deal that actually took years to work out, since it unifies classes and types in the language. I am far more confident that it is correct after having worked out exactly how it gets implemented.

2. I produced an implementation paper for classes. This is a gathering of previous material along with how exactly it applies to P6. I would like to publish implementation papers (there are actually a lot of them), but frankly they turn out to be wrong so often I don't think it would help anyone, least of all me. However, the implementation paper is the last step before performing the work, so it is an interesting milestone.

This is it for now, in terms of status.

I have been studying the language Go, from Google, which has got a lot of press lately. You probably would not be surprised that I consider Pascaline to be a better language, abet more complex. Go, like other languages, attempts to get back to static type checking. How many times have I said that type checking is a requirement to get to secure multitasking.

I was genuinely shocked by some aspects of Go that I really did not expect to find:

• Go treats unicode as multibyte character sequences using UTF-8! What a huge step backwards! I really don't understand that one. UTF-8 is an I/O format, NOT an internal representation.
• Despite including multitasking built into the language, Go expects you to perform your own multithread task locking to protect shared variables! If you are going to put multitasking in the language, then put it there. The user should not see or even know about locking at the language level. I guess what the authors of Go were saying here is they had no plan to place variables into common regions like Pascaline does with monitors, and indeed Go does not have monitors. So channels are a good, multiple use construct but they don't cover everything. Monitors have been around since the 1960s, so you can't use the excuse you didn't know about this requirement.
• Go is said to be statically typed, but slices are not static typing. Rather they are dynamic typing with pointers. Let's call things what they are please.
• Go escews inheritance. Ok, so there is a movement afoot that states inheritence is bad, is a bad idea. I read the various arguments. The standard object style is "encourages breaking program code down into small bits", I.E., classes and methods to do small things, like form iterators, etc. I actually like inheritence a lot even though the vast majority of my code is procedural. Pascaline does not pick or encourage a particular style, and it specifically tries to get away from the need to make classes small bits of code. The only requirement that is different between modules and classes is that classes must be contained in modules. To me this made perfect sense, because modules have form as static objects and classes are a type form for actual objects to be instantiated at a later time.

I found it strange that no high performance compilers exist for go or are planned. Saying that go is a "higher level language" and therefore not expected to perform, I think is a cop-out. A general purpose language that is not performant is not a general purpose language, IMHO.

Finally, I think any language supporting parallelisim should have as a long term goal hardware translation. Are you shocked by that? Good.

Regards,

Scott Franco

[Scott Franco]

A PS go that:

It occurred to me that my comments about the Go language could offend some folks. I am well aware of the meme. I have stood up, both virtually and in a conference, and said stated what I believe about a programming language or a particular peice of code and have encountered the retort:

"you just said XXX is wrong. That was programmed by John H. Doe, who everyone here acknowledges as a genius. Are you smarter than he is?".

And so it goes. My crime above would be questioning the great Brian W Kernighan. Let's put a few facts on the table:

1. I respect Professor Kernighan quite a lot. Because I disagree with someone does not mean I disrespect them.
2. The Go project cites Professor Wirth's and Professor Hoare's work, and specifically the book "communicating sequential processors". Unfortunately the Monitor concept, described as joinly invented by Professor Hansen and Professor Hoare (they actually cite each other as the inventor), is unused and unmentioned. In fact, before his death, Per Brinch Hansen specifically wrote about the lack of multitask security in modern languages, specifically Java.
3. In the book "the Go programming language" [Donovan and Kernighan], in the chapter "concurrency with shared variables" they discuss mutex locking (they even use the word "monitor", even though in a comment). Multitask data corruption issues are clearly discussed, and the solution given is to manually lock and unlock sections of data.

And so I respectfully disagree that this is a good idea, for the following reasons:

1. Leaving this to the programmer puts the responsibility for very difficult and complex multitask bugs back on to the programmer, something the Go language was supposed to fix.
2. Putting a monitor concept into the language allows the compiler to place appropriate syncronisation primitives into the code were needed. Not just locks, but also memory barriers, cache line flushing, etc. In short Go hides the fact it has entered a critical section from the compiler.
3. This construct is untranslatable to true parallel implementations and perhaps hardware (see for example OpenCL). Again the criical section is not specifically marked off (unless the compiler is supposed to figure out the locking statement order and range).

Scott Franco