On Sat, Jun 20, 2015 at 11:18 AM, Bill Frantz <[email protected]> wrote:
> While I am also concerned with the problem of ever-expanding languages > because the larger they grow, the harder they are to learn, and the harder > it is to read someone else's code which uses unfamiliar features, there are > other issues that are equally important. > > I find the most unappreciated feature of a language is the list of things > it can't do. For a bit of background, my first program was written in > machine language, and after struggling with it, the instructor introduced > the class to a wonderful tool: assembler language. Sufficient to say, I > know about languages with built in footguns. > > The advantage of having a language that doesn't allow certain things is > that you don't have to worry about them when you are debugging or reviewing > a program. Memory safety is high on the list of useful features which JS > has. Another very valuable feature is the ability to limit what a piece of > code can do before you invoke it. In the JS arena, this kind of limitation > allows web sites which give their users security assurances to run > arbitrary JS provided by advertisers. ES2015 has a number of features to > support this usage, but because of the need to not "break the web", they > are a bit delicate to use. > > It would be good to include a list of the things you can't do in the > language specification so failures in this area are clearly bugs in either > the implementation or the specification. I would suggest for JS that this > list include the things required for confining a piece of JS code running > within a larger environment, like a web page to keep it from doing all the > things the web page can do. > Hi Bill, regarding the list of bullets On Fri, Jun 19, 2015 at 11:12 AM, Mark S. Miller <[email protected]> wrote: > > * fundamental syntax -- the special forms that cannot faithfully be > explained by local expansion to other syntax > * semantic state -- the state than computation manipulates > * kernel builtins -- built in library providing functionality that, if > it were absent, could not be provided instead by user code. > * intrinsics -- libraries that semantic state or kernel builtins depend > on. For example, with Proxies, one might be able to do Array in user code. > But other kernel builtins already have a dependency on Array specifically, > giving it a privileged position over any replacement. > * syntactic sugar -- the syntax that can be explained by local expansion > to fundamental syntax. > * global convenience libraries -- could be implemented by unprivileged > user code, but given standard global naming paths in the primordial global > namespace. > * standard convenient library modules > your point is another reason to prioritize the first four bullets over the last three. To understand what can't be done requires a deep understanding of at least the first three and arguably the fourth. However, the last three bullets cannot have any effects on the inabilities provided by a language. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
