Jonathan Rees

I think what Andrew Hejlsberg himself, the designer of C# and TypeScript, said speaks to the claims orange8 is making about TypeScript being a "VERY opinionated linter" and that "you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns".

Andrew Hejlsberg's point is that TypeScript is a "multi-paradigm" language: it's not just strongly typed, but also structurally typed, interface based, plus everything else JavaScript itself is: dynamically typed, duck typed, functional, imperative, event driven, class based, prototype based, object oriented, etc.

Even the term "object oriented" has a broad spectrum of independent meanings: JavaScript has many but not all of the a la carte menu of features or properties of "object orientation" that Jonathan Rees listed in response to Paul Graham's essay "Why Arc isn't Especially Object-Oriented".

http://paulgraham.com/reesoo.html

http://mumble.net/~jar/articles/oo.html

http://paulgraham.com/noop.html

Andrew Hejlsberg said:

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

It's a mistake to think that TypeScript restricts you to just one way of programming, and you have to give up the ways you used to program JavaScript. TypeScript ADDS to the number of ways you can program JavaScript. It's a superset of the multiple programming paradigms that JavaScript supports.

You don't "loose a…

You may find this paper helpful [1]. As noted there, syntax-rules consists really of two different parts: (1) the hygiene-preserving macro expander and (2) the pattern-matching facility. Once you wrap your head around the two pieces, it's actually pretty straightforward to implement them both. It's very common to write some "low-level" macro facility as a stepping-stone to syntax-rules (such as explicit-renaming macros or syntactic closures): the implementation of syntax-rules then becomes a composition of the pattern-matcher and the low-level facility. A tutorial implementation of an appropriate pattern-matcher can be found at [2],[3].

There's lots of good reading to be found at the ReadScheme Library [4]. Most if not all of the references in [1] can be found there.

Tangentially: yeah, syntax-rules kinda flies in the face of the oft-mentioned minimalism of Scheme, but there's a reason for it: at the time syntax-rules was standardized, there was no consensus on which (if any) low-level facility should be standardized (and, really, there still isn't any such consensus). The reason syntax-rules operates as a pattern-template rewriting system rather than as a procedural system is that such a system is able to guarantee that the macros it produces are hygienic in a (comparably) simple and intuitive way. The idea was to standardize on a high-level system so that Scheme could have a standard macro facility, whilst leaving the low-level systems open for further…

Interestingly, one of the pages you link (http://mumble.net/~jar/tproject/) links a paper (grep "1986: Kelsey dissertation on rewrite-based compilation
") that shows the implementation of a compiler with multiple frontends (BASIC, Scheme, Pascal) using only source-to-source) transformation.

I find this interesting because in a certain way, this reminds me of how the go assembler works (https://www.youtube.com/watch?v=KINIAgRpkDA).

For those who haven't seen the talk: basically the go compiler works on the assumption that pretty much all computer, in a way, move memory from one address to another, generate and handle interrupts, have call/return instructions and so on. Thus, the go compiler emits (IIRC) some sort of "intermediate assembler" (somehow similar to llvm's intermediate representation, but simpler) and then proceeds to "translate" such assembler to various platform native assembler. I clearly remember Rob Pike (in the talk) saying "so the task of supporting a new platform becomes a task in text processing" (okay, maybe it was worded a bit better).

This might be a bit tangential, but it is interesting how some "new" ideas aren't that new after all. But I guess this is due to Rob Pike's deep experience and history with computers.

Douglas Crockford has described Misty as vaporware (hence the name), whereas at Spritely we are building and shipping things that can be used. Rather than build an entirely standalone domain specific language, our research and development builds on top of Scheme because it's a multi-paradigm language that is easy to extend to implement new paradigms (such as the actor model) thanks to the powerful macro system. Lexical scope and first-class functions make Scheme amendable to the actor model (Scheme was initially created as an exploration of the actor model) and capability security. For the latter, we are inspired by Jonathan Rees' W7: A security kernel based on the lambda calculus.

http://mumble.net/~jar/pubs/secureos/secureos.html

We are also involved in a cross-organization effort to bring capabilities to everyone (on the network, at least) called OCapN and we are seeking implementers for as many programming languages as possible.

https://ocapn.org/

Bash may need a high level of authority as it's spawning processes and wiring them together, but those processes don't necessarily need to have as much access as you do themselves.

Take the venerable `cowsay` for example. Currently, running `cowsay` (as with any other program) can cryptolocker your hard drive, delete all your files, reach out to arbitrary servers on the internet, etc. But how much access to your system does it actually need to do its job? Well, mostly... STDIN, and STDOUT, really.

Yes, actually doing this is complicated. Another reply has linked to some broad info about object-capability security, but here's a good introduction to the subject: http://habitatchronicles.com/2017/05/what-are-capabilities/

...and this paper is an excellent deep dive into a capability system: https://mumble.net/~jar/pubs/secureos/secureos.html

One of earlier works combining high-security and functional programming was a security kernel for Scheme48:

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.4213

http://mumble.net/~jar/pubs/secureos/

That was the Scheme mathematically-verified in VLISP project:

https://en.wikipedia.org/wiki/PreScheme

There was also a mathematically-verified, Scheme CPU:

http://www.cs.indiana.edu/pub/techreports/TR544.pdf

I imagine combining even these three components into an integrated systems would provide a lot more security and availability than the average desktop. The simplicity of the CPU might also aid in producing a NonStop-like solution for five 9's availability.