5 ms·

My general feeling is that these un-features take things away, and what they purport to provide in exchange is fewer bugs by virtue of being able to check certa

My general feeling is that these un-features take things away, and what they purport to provide in exchange is fewer bugs by virtue of being able to check certain constraints at ‘compile time’. I’m all for taking things away, but I personally want more in exchange. For example, if you’re going to give me immutable or const declarations, give me lazy evaluation as part of the bargain. So I’m not opposed to taking things away, I am just optimistic that we can provide a lot more value than ‘constraints’ in exchange. And if we aren’t going to provide more value, I think we’re setting our sights too low.

politician 15y ago
Have you considered the value that these keywords add to a team environment, or as reminders when visiting an api that you haven't worked on in months? It's something a little more standardized than "_privateVar" and "maxCount =4; // NOTE: Constant Variable!"
- raganwald 15y ago
  I have, and speaking as a guy who spent a big chunk of his career working with large teams on large code bases, I think private and const are small potatoes next to really big domain-specific semantic constraints. So to me, providing small value in exchange for making other things harder to do is not a win. It feels like we're circling around a local maximum and nobody is trying to make a really big leap when thinking about JS.next. We're getting the warmed-over leavings of middle-of-the-road language ideas. If you really want constraints that are tailored for a team environment, make them programmable and put const and private in the standard lib. Then let Alice write something that prevents Bob from putting text in a SQL query or opening up an XSS vector in raw HTML. Or let Carol write something that ensures that all code makng certain writes to the database have an authorization check baked in.
  - lincolnq 15y ago
    Thanks. Contracts are an AWESOME idea and I would love to see them make it into a language that everyone uses. The ideas behind powerful contracts / type systems have been around for a long time: provide properties that are checked such that you can rely on them. It seems an interesting and difficult problem to try to add a general enough contract system to javascript, which would support things like const and private and "account balance is always positive". But I think that if done well, it would be the single defining feature which would draw me into using a language. Man, would that be awesome.
    - disnet 15y ago
      Not sure if const/private are a good fit for contracts but things like "account balance is always positive" can be done right now with contracts.coffee using object invariants. For example, verifying the invariants of a binary search tree hold [1]. [1] http://disnetdev.com/contracts.coffee/#duck http://disnetdev.com/contracts.coffee/#duck
      - lincolnq 15y ago
        You just made me look seriously into coffeescript. Thanks!
  - BrendanEich 15y ago
    FYI, http://disnetdev.com/contracts.coffee/ http://disnetdev.com/contracts.coffee/ is built on ES6 proxies and CoffeeScript. I agree on circling a local maximum, but some of this is just JS catching up to Ruby and Python. Syntactic affordances for usability that desugar to only lightly extended kernel semantics. The big ticket items are modules, proxies, weak maps, binary data, and the like. When I liken JS to x86, I'm not comparing it to assembly so much as to a ubiquitous target for compilation. JS is even stickier and longer-lived than x86 -- witness ARM's rise on mobile while the web evolves mostly-compatibly, including JS content and the JS language. Contracts and macros are on the Harmony agenda, further out.
    - Andi 15y ago
      I came across contracts some time ago and found it very appealing and inspiring, but for all my professional projects I am successfully using my own library schema.js ( https://github.com/akidee/schema.js https://github.com/akidee/schema.js ) - you can use it in pure JavaScript, too. (Usually I do not validate forms on the client-side, since the data must be validated on the server-side anyway. And with schema.js, you can add custom localized error messages.) Furthermore, schema.js has several modes that allow tolerant adaptation of values, so that they can be casted. "5", for example, is casted to 5. But you can switch to strict validation mode as well. You can do everything, that contracts allows, with schema.js, too. The best is that, with JSON schema, 1) you define secure validations, since with the default properties you do not forget important constraints, and 2) you do not need to test your validators any more. Conclusion: I agree that such features must make it to the core of a language. Probably you can find some useful ideas in JSON schema and schema.js. I found the JSON vocabulary to be very useful to validate JS data.
    - raganwald 15y ago
      Thanks, I like Design By Contract(tm) and this looks very interesting.

politician 15y ago

Have you considered the value that these keywords add to a team environment, or as reminders when visiting an api that you haven't worked on in months? It's something a little more standardized than "_privateVar" and "maxCount =4; // NOTE: Constant Variable!"

raganwald 15y ago
I have, and speaking as a guy who spent a big chunk of his career working with large teams on large code bases, I think private and const are small potatoes next to really big domain-specific semantic constraints. So to me, providing small value in exchange for making other things harder to do is not a win. It feels like we're circling around a local maximum and nobody is trying to make a really big leap when thinking about JS.next. We're getting the warmed-over leavings of middle-of-the-road language ideas. If you really want constraints that are tailored for a team environment, make them programmable and put const and private in the standard lib. Then let Alice write something that prevents Bob from putting text in a SQL query or opening up an XSS vector in raw HTML. Or let Carol write something that ensures that all code makng certain writes to the database have an authorization check baked in.
- lincolnq 15y ago
  Thanks. Contracts are an AWESOME idea and I would love to see them make it into a language that everyone uses. The ideas behind powerful contracts / type systems have been around for a long time: provide properties that are checked such that you can rely on them. It seems an interesting and difficult problem to try to add a general enough contract system to javascript, which would support things like const and private and "account balance is always positive". But I think that if done well, it would be the single defining feature which would draw me into using a language. Man, would that be awesome.
  - disnet 15y ago
    Not sure if const/private are a good fit for contracts but things like "account balance is always positive" can be done right now with contracts.coffee using object invariants. For example, verifying the invariants of a binary search tree hold [1]. [1] http://disnetdev.com/contracts.coffee/#duck http://disnetdev.com/contracts.coffee/#duck
    - lincolnq 15y ago
      You just made me look seriously into coffeescript. Thanks!
- BrendanEich 15y ago
  FYI, http://disnetdev.com/contracts.coffee/ http://disnetdev.com/contracts.coffee/ is built on ES6 proxies and CoffeeScript. I agree on circling a local maximum, but some of this is just JS catching up to Ruby and Python. Syntactic affordances for usability that desugar to only lightly extended kernel semantics. The big ticket items are modules, proxies, weak maps, binary data, and the like. When I liken JS to x86, I'm not comparing it to assembly so much as to a ubiquitous target for compilation. JS is even stickier and longer-lived than x86 -- witness ARM's rise on mobile while the web evolves mostly-compatibly, including JS content and the JS language. Contracts and macros are on the Harmony agenda, further out.
  - Andi 15y ago
    I came across contracts some time ago and found it very appealing and inspiring, but for all my professional projects I am successfully using my own library schema.js ( https://github.com/akidee/schema.js https://github.com/akidee/schema.js ) - you can use it in pure JavaScript, too. (Usually I do not validate forms on the client-side, since the data must be validated on the server-side anyway. And with schema.js, you can add custom localized error messages.) Furthermore, schema.js has several modes that allow tolerant adaptation of values, so that they can be casted. "5", for example, is casted to 5. But you can switch to strict validation mode as well. You can do everything, that contracts allows, with schema.js, too. The best is that, with JSON schema, 1) you define secure validations, since with the default properties you do not forget important constraints, and 2) you do not need to test your validators any more. Conclusion: I agree that such features must make it to the core of a language. Probably you can find some useful ideas in JSON schema and schema.js. I found the JSON vocabulary to be very useful to validate JS data.
  - raganwald 15y ago
    Thanks, I like Design By Contract(tm) and this looks very interesting.