Grawlix
GrawlixScript is the connection I guess.
jjb
On 11:59 AM, John J Barton wrote:
GrawlixScript is the connection I guess.
No, grawlix is a term of art that can be used to describe some the literal syntax proposals.
JavaScript's original C-like syntax used symbols for limited purposes. Consequently developers familiar with, for example C and Java, could read most of the code and concentrate on the new things. This greatly lowered the barrier to entry. While theoretically there is nothing magical about the C-like syntax, practically it really helps. (Famous exceptions include of course "this", (looks like Java; isn't like Java), and highly nested function definitions marching ever rightward).
Recent syntax discussions head in a completely different direction, introducing a seemingly large number of new symbols resulting in code that isn't readable by current JS, Java, or C devs. Instead of JavaScript they will be attempting to read GrawlixScript. I'm skeptical that this direction will be welcomed by developers.
jjb
On 06/10/11 19:56, John J Barton wrote:
Recent syntax discussions head in a completely different direction, introducing a seemingly large number of new symbols resulting in code that isn't readable by current JS, Java, or C devs. Instead of JavaScript they will be attempting to read GrawlixScript. I'm skeptical that this direction will be welcomed by developers.
There already is lots of complaints about syntax from developers, and they always spring up when someone brings ES.next topic on ##javascript's IRC channel, for example.
Though I do believe there are two different groups in this case, those who want syntax either for static/contracts or conciseness, and those who don't want syntax because it makes the language needlessly complex --- neither opposing all syntax proposals or accepting all of them.
My personal opinion is that syntax should be kept minimal, while maintaining expressivity. Usually, well designed APIs provide a more expressive interface because you can mix and match them, and they are usually far cheaper (in complexity) than their syntaxes counterpart.
Surely, where APIs would otherwise add too much boilerplate, we need syntax. But I don't think that, in a highly dynamic language like JS, declarative/static syntax for every construct should be a major concern. But then, I'm no language designer, only a regular user. And perhaps I've been too much spoiled by Scheme.
On this particular issue, I'm inclined to agree -- I think we should be extremely sparing with how many new sigils, if any, we introduce into the language. You'll notice Brendan has repeatedly said similar things about <| and .{ for example. Syntax matters.
But I feel like now might be a good time for a reminder (probably belongs in a FAQ!):
Design is a process. In the beginning, you consider lots of needs and use cases and you generate lots of ideas. As you go along, you iterate on these ideas to try to come up with the simplest, most parsimonious, most general-purpose, and most composable core elements you can find that address as many of these needs as possible. Later in the process, you start prioritizing, culling, and polishing.
Generally speaking, during this process, new needs and new issues arise. So typically this process is actually happening in many parallel strands, each of which is at a different phase of the design process. Of course, design is a holistic thing, so they often affect each other, sometimes forcing one thread that appeared to be stabilizing back into an earlier phase to iterate anew.
TC39 does our design work out in the open. That means everyone gets to see and participate in all parts of this process. The most common misunderstanding that arises is that TC39 is on the brink of standardizing on every single idea that has been considered. However, this has never been and will not be (at least as long as I'm part of this process) the case. But you can't short-cut the process. You can't pick the winners until you've let all the ideas run their course.
On Oct 6, 2011, at 4:25 PM, Quildreen Motta wrote:
On 06/10/11 19:56, John J Barton wrote:
Recent syntax discussions head in a completely different direction, introducing a seemingly large number of new symbols resulting in code that isn't readable by current JS, Java, or C devs. Instead of JavaScript they will be attempting to read GrawlixScript. I'm skeptical that this direction will be welcomed by developers.
I assume that this remark is primarily direct at <| and .{
The other "new operators" that I can immediately think of are using # as was proposed by Brendan at the last TC39 meeting to tag frozen properties in obj literals, the use of ` to delimit quasis, and the use of [ ] to identify evaluated property naming expressions (usually private name references). There may be one or two others that I'm forgetting right now.
There have been earlier proposals that are no longer active that have included other uses of special symbols such as an orthogonal set of attribute modifiers.
There are also straw-men floating around such as arrow functions and block lambdas that have not (yet) been accepted into ES.next.
I also argue that .{ and [privateNameRef] are not really "new symbols" but instead attempts to build upon the existing symbology of the language in order to address new use cases.
So, I have a really hard time understanding the "seeming large number of new symbols" remark above. If there is such a perception in the community, then I suspect that it is really a reaction to something other than what that statement suggests.
As far as I'm aware, there are fundamentally only a few ways to express a new semantic concept in JavaScript: a new multi-character symbolic operators or delimiter (we've exhausted the supply of typable single char alternatives), for example: <| a new contextual non-reserved identifier based operator (used sparingly because of ASI issues), for example: is a new reserved word (sometime we try to avoid except for the future reserved words), for example: module or class a build-in function or method, for example: Object.extend
These all have their place and are all being used in ES.next.
I can't speak for other designers, but I thiink they would agree that typically we explore and float ideas for all of these alternatives when exploring the design space for a new language features.
For example, we were looking for a more concise way to express obj = Object.defineProperty({}, 'length', {value: 3}); //note attributes default to: configurable: false, writable: false, configurable: false because feedback form ES5 was that the wordiness and default attribute values we preventing wide use of explicitly attribute control.
My first proposals for adding an orthogonal set of attribute modifies to object literals was completely based upon the use of contextual keywords. For example: obj = {sealed const length: 3}; to mean a data property whose properties are non-enumerable, writable, and non-configurable (see strawman:obj_initialiser_const ). The net feedback on this proposal was that it didn't feel like JavaScript because it was too wordy.
So, the next proposal (strawman:concise_object_literal_extensions)was to use symbolic attribute modifiers: obj = {~! length:= 3}; The net feedback was that it was unreadable chicken-scratches.
So, the community (more likely, different segments of the community) having rejected the two most likely approaches to the problem of providing control of property attributes in object literals, I concluded that nobody currently had a viable solution for this problem and I dropped the proposals. The usage keeps coming up as a problem and hence the {#length:3} idea from the last TC39 meeting. We'll see how well that sticks at the community level.
Similarly, prior to <| I explored (I believe on this list) various identifier based alternatives. For example: var obj = parent proto { ...}; but note it also allows for things like: var obj = proto proto {...}; We explored various possible words such as: var obj = parent prototypeof {...}; There was various feedback about word choice, length, how well it standards out in text, etc. This lead to a preference for the symbolic operator path and of those I still think that <| is the best alternative (but <: isn't bad either).
Bottom line, I disagree with John J's initial premise about the path we are on. I also am convinced that for all design choices we make(I'm not just talking about syntax here) there will be loud voices with objections. It is important that we listen to them. However, if community wide consensus determined from tweets, blog posts, and discussion list message is going to be necessary for every new feature to go forward then we might as well stop working on future ES revisions.
There already is lots of complaints about syntax from developers, and they always spring up when someone brings ES.next topic on ##javascript's IRC channel, for example.
I think there is another phenomena at play here. First encounters with new symbolisms are never easy. It forces you to come to a full stop and then go off and learn the meaning of the symbols before you can proceed. var obj = extensions <| [1,2,3]; //WTF is this!!! Words based symbols appear to be meaningful by themselves: var klass = SuperK prototypeof function() {...}; //I think I understand (but you probably really don't) If the words are well chosen, upon first encountered you can quickly form a theory about what they mean and proceed without actually learning the real meaning. There is, of course, a danger in this. Also, this only applies to readers who a fluent speakers of the natural language from which words are being chosen. I'm confident that if the alternative to <| was a Chinese word or phrase we would not even be having this discussion on this list.
I believe, that many of the IRC or Twitter comments about syntax are from people who see things like allenwb/ESnext-experiments/blob/master/ST80collections-exp1-nocomma.js#L108-152 and respond without stopping to learn the symbology. I think there is some, but pretty limited value, in such feedback. I'm much more interested in real usage feedback were people have taken the time to learn the symbology and then really tried to exercise it as a reader writter. That is the sort of usability testing that really matters.
From: Allen Wirfs-Brock <allen at wirfs-brock.com> Subject: Re: Grawlix Date: October 7, 2011 19:56:23 GMT+02:00 To: Quildreen Motta <quildreen at gmail.com>, John J Barton <johnjbarton at johnjbarton.com> Cc: es-discuss at mozilla.org
For example, we were looking for a more concise way to express obj = Object.defineProperty({}, 'length', {value: 3}); //note attributes default to: configurable: false, writable: false, configurable: false because feedback form ES5 was that the wordiness and default attribute values we preventing wide use of explicitly attribute control.
My first proposals for adding an orthogonal set of attribute modifies to object literals was completely based upon the use of contextual keywords. For example: obj = {sealed const length: 3}; to mean a data property whose properties are non-enumerable, writable, and non-configurable (see strawman:obj_initialiser_const ). The net feedback on this proposal was that it didn't feel like JavaScript because it was too wordy.
So, the next proposal (strawman:concise_object_literal_extensions)was to use symbolic attribute modifiers: obj = {~! length:= 3}; The net feedback was that it was unreadable chicken-scratches.
So, the community (more likely, different segments of the community) having rejected the two most likely approaches to the problem of providing control of property attributes in object literals, I concluded that nobody currently had a viable solution for this problem and I dropped the proposals. The usage keeps coming up as a problem and hence the {#length:3} idea from the last TC39 meeting. We'll see how well that sticks at the community level.
I like it. I would like ES.next to be as lightweight as possible (and all currently accepted proposals do that). If we need role models, they should be Smalltalk and Lisp, not some of the more static languages. Then, the most frequent use cases (in non-security-related code) are: configurable+writable and non-configurable+non-writable (with a fixed value). The above sticks with the established "#" indicating “read-only-ness”.
The main problem that I have with property descriptors is that they are an either-or proposition; you can’t mix their use with normal assignments. A method Object.prototype.defineProperty would be an easy solution:
var obj = { count: 3, }.defineProperty("MAX_COUNT", { value: 10, writable: false, configurable: false });
This lead to a preference for the symbolic operator path and of those I still think that <| is the best alternative (but <: isn't bad either).
+1
Bottom line, I disagree with John J's initial premise about the path we are on. I also am convinced that for all design choices we make(I'm not just talking about syntax here) there will be loud voices with objections. It is important that we listen to them. However, if community wide consensus determined from tweets, blog posts, and discussion list message is going to be necessary for every new feature to go forward then we might as well stop working on future ES revisions.
Agreed. Statistically, for every 5% of people who make their voice heard, there are 95% that are keeping quiet.
On Fri, Oct 7, 2011 at 11:26 AM, Axel Rauschmayer <axel at rauschma.de> wrote:
*From: *Allen Wirfs-Brock <allen at wirfs-brock.com>
+1
Bottom line, I disagree with John J's initial premise about the path we are on. I also am convinced that for all design choices we make(I'm not just talking about syntax here) there will be loud voices with objections. It is important that we listen to them. However, if community wide consensus determined from tweets, blog posts, and discussion list message is going to be necessary for every new feature to go forward then we might as well stop working on future ES revisions.
Agreed. Statistically, for every 5% of people who make their voice heard, there are 95% that are keeping quiet.
I hope you will reconsider. The 5% who speak up are exactly the people who need to be convinced. They are the ones interested in this work; they are the ones who can advocate for implementation, educate other developers, and bring the new technology into full use. They are you users. The practical way to understand what the 95% would say if you asked them is to listen to the 5%.
Listening is not seeking consensus. Listening is the best path to learning how to communicate the ideas better. It is also the best path to realizing that most JS developers have nothing like the amount of time you do to learn to be effective with sophisticated abstractions.
Expecting to base evaluation on some form of user testing as Allen proposes is, in my experience completely hopeless. As Allen notes this kind of feature requires in depth use. In this case that will be months not minutes. Even then I'd be skeptical User testing results are almost always 'cooked', arranged by the experimenter to create the result they seek. They do have value, primarily because the process of creating the test and explaining to the user flushes out a lot of bugs in ideas and their presentation. User testing for certain kinds of user interface changes can be effective, but its way out of its range here.
jjb
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
On Wed, Oct 12, 2011 at 6:18 PM, Mikeal Rogers <mikeal.rogers at gmail.com>wrote:
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
+1
On Wed, Oct 12, 2011 at 7:18 AM, Mikeal Rogers <mikeal.rogers at gmail.com> wrote:
those who spend the majority of their time designing languages.
Speaking as someone who knows a very large number of language designers, no one in the world spends most of their time designing languages. People responsible for language design should, and do, spend most of their time programming. This is certainly true of members of TC39 -- Dave and Mark and Allen and Brendan and Alex and Doug and Arv and Tom are all authors of software that you can download.
What are you saying? I see two possible interpretations of what you have written.
Interpretation 1: If someone has actually used the new language features (not just the language) then they should be listened to? => I agree 100%.
Interpretation 2: There are two groups of people on this mailing list: Those who design languages and those who actually program. The former group has proposed language features that might be of academic value, but have little real-world use. => I don’t agree. I really like the work that has been done so far. I consider myself to be part of both groups you mention, probably more in the programmer camp than the language designer camp.
On Oct 12, 2011, at 13:18 , Mikeal Rogers wrote:
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
How do you know that these two groups are disjunct? This sounds a little insulting.
On Wed, Oct 12, 2011 at 7:05 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
What are you saying? I see two possible interpretations of what you have written.
Interpretation 1: If someone has actually used the new language features (not just the language) then they should be listened to? => I agree 100%.
Interpretation 2: There are two groups of people on this mailing list: Those who design languages and those who actually program. The former group has proposed language features that might be of academic value, but have little real-world use. => I don’t agree. I really like the work that has been done so far. I consider myself to be part of both groups you mention, probably more in the programmer camp than the language designer camp.
On Oct 12, 2011, at 13:18 , Mikeal Rogers wrote:
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
How do you know that these two groups are disjunct? This sounds a little insulting.
Apologies for the lack of diplomacy and arrogance that could be inferred from this post, slightly short on time.
From my point of view ( as a programmer who spends the vast majority of his
time in 'real-world' javascript - I have to admit that I have trouble recognizing the impetus for and rationales behind some of the changes argued for throughout the list ( Apologies for not being too specific at this point ).
There have been comments regarding ES becoming / being "an assembler language" - making it more amenable to letting people work in languages where they are more proficient / comfortable or otherwise expect a productivity advantage.
This seems to closely mirror my experience in my current work environment - where Rails devs unfamiliar with available JS frameworks and patterns find CoffeeScript an attractive alternative to acquiring new skills ( to be blunt and superficial ).
I think that statements such as "highly nested function definitions marching ever rightward" should raise a red flag - indicative more of unfamiliarity with named functions and scope binding rather than actual language deficiencies.
I think an important question here is: Who are you actually trying to serve with your changes?
-- Joe Developer
On Oct 12, 2011, at 6:53 AM, Joe Developer wrote:
I think an important question here is: Who are you actually trying to serve with your changes?
See the actual goals requirements and goals for ES Harmony at harmony:harmony
Requirements New features require concrete demonstrations. Keep the language pleasant for casual developers. Preserve the “start small and iteratively prototype” nature of the language. Goals
Be a better language for writing: complex applications; libraries (possibly including the DOM) shared by those applications; code generators targeting the new edition. Switch to a testable specification, ideally a definitional interpreter hosted mostly in ES5. Improve interoperation, adopting de facto standards where possible. Keep versioning as simple and linear as possible. Support a statically verifiable, object-capability secure subset.
On Wed, Oct 12, 2011 at 8:32 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
On Oct 12, 2011, at 6:53 AM, Joe Developer wrote:
I think an important question here is: Who are you actually trying to serve with your changes?
See the actual goals requirements and goals for ES Harmony at harmony:harmony
Requirements
- New features require concrete demonstrations.
- Keep the language pleasant for casual developers.
This is a great response. All I was trying to say with the shorthand 'GrawlixScript' is that some of the concrete demonstrations fail the second test. Of course requirements and goals conflict, I was just trying to put a voice in on the side of #2.
jjb
On Oct 12, 2011, at 9:53 AM, Joe Developer wrote:
On Wed, Oct 12, 2011 at 7:05 PM, Axel Rauschmayer <axel at rauschma.de> wrote: What are you saying? I see two possible interpretations of what you have written.
Interpretation 1: If someone has actually used the new language features (not just the language) then they should be listened to? => I agree 100%.
Interpretation 2: There are two groups of people on this mailing list: Those who design languages and those who actually program. The former group has proposed language features that might be of academic value, but have little real-world use. => I don’t agree. I really like the work that has been done so far. I consider myself to be part of both groups you mention, probably more in the programmer camp than the language designer camp.
On Oct 12, 2011, at 13:18 , Mikeal Rogers wrote:
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
How do you know that these two groups are disjunct? This sounds a little insulting.
Apologies for the lack of diplomacy and arrogance that could be inferred from this post, slightly short on time.
Why are you replying to Axel's reply to Mikeal?
Who are you, anyway?
From my point of view ( as a programmer who spends the vast majority of his time in 'real-world' javascript - I have to admit that I have trouble recognizing the impetus for and rationales behind some of the changes argued for throughout the list ( Apologies for not being too specific at this point ).
Vague and useless, apology means nothing.
There have been comments regarding ES becoming / being "an assembler language" - making it more amenable to letting people work in languages where they are more proficient / comfortable or otherwise expect a productivity advantage.
That's a goal, one among many. They compete, and that goal is not the most important by a long shot.
This seems to closely mirror my experience in my current work environment - where Rails devs unfamiliar with available JS frameworks and patterns find CoffeeScript an attractive alternative to acquiring new skills ( to be blunt and superficial ).
That's actually a good point, don't apologize for it. CoffeeScript is better for Rubyists, and if those who learn it then can probably be more productive using it than JS.
I think that statements such as "highly nested function definitions marching ever rightward" should raise a red flag - indicative more of unfamiliarity with named functions and scope binding rather than actual language deficiencies.
No, because the nested functions are closing over outer variables, typically. Manually lambda-lifting and passing extra parameters is ugly and costly, no one should do it by hand.
Some say nesting, those who decry it should toughen up. This ignores two problems:
-
Closures can be the best, safest, most concise way to use continuation passing style, but they can bite back if too much is entrained, and you get a leak. Erik Corry's JSConf.eu talk showed examples.
-
Nesting to high indentation level can be annoying to write and read.
These aren't the end of the world, but they keep coming up as real problems for many programmers.
On Thu, Oct 13, 2011 at 2:07 AM, Brendan Eich <brendan at mozilla.com> wrote:
On Oct 12, 2011, at 9:53 AM, Joe Developer wrote:
On Wed, Oct 12, 2011 at 7:05 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
What are you saying? I see two possible interpretations of what you have written.
Interpretation 1: If someone has actually used the new language features (not just the language) then they should be listened to? => I agree 100%.
Interpretation 2: There are two groups of people on this mailing list: Those who design languages and those who actually program. The former group has proposed language features that might be of academic value, but have little real-world use. => I don’t agree. I really like the work that has been done so far. I consider myself to be part of both groups you mention, probably more in the programmer camp than the language designer camp.
On Oct 12, 2011, at 13:18 , Mikeal Rogers wrote:
I would implore those doing this design work to offer greater weight to the options of people who are using the language more than they are spending their time on this list.
Users are generally under-represented on standards, we're lucky enough to have some here, I would take their feedback much more seriously than those who spend the majority of their time designing languages.
How do you know that these two groups are disjunct? This sounds a little insulting.
Apologies for the lack of diplomacy and arrogance that could be inferred from this post, slightly short on time.
Why are you replying to Axel's reply to Mikeal?
My contribution to this thread was precipitated by the constellation of comments regarding JS programmer feedback - this happened to be the last post in the thread at the time and espoused the view, basically, that users of exclusively the current production environment language shouldn't have a voice in the direction of the language they will be using going forwards.
Who are you, anyway?
Vague and useless by some estimations, apparently. If you have specific metrics in mind for what defines a person then feel free to ask to them.
From my point of view ( as a programmer who spends the vast majority of his time in 'real-world' javascript - I have to admit that I have trouble recognizing the impetus for and rationales behind some of the changes argued for throughout the list ( Apologies for not being too specific at this point ).
Vague and useless, apology means nothing.
What do you hold to be vague exactly? The comments on the thread related to language designers vs language users - somewhat problematically the term 'programmer' used in the thread could be interpreted to include people spending most of their times in other languages. My intention was to avoid ambiguity - I currently develop exclusively in JS.
Apologizing for not pointing to specific proposals holds meaning for me.
There have been comments regarding ES becoming / being "an assembler language" - making it more amenable to letting people work in languages where they are more proficient / comfortable or otherwise expect a productivity advantage.
That's a goal, one among many. They compete, and that goal is not the most important by a long shot.
While I can empathize with the abstract desire to be able to use a preferred language in lieu of something else - I have to admit that I worry about possible consequences of concessions to this goal, to be vague and useless yet again.
This seems to closely mirror my experience in my current work environment - where Rails devs unfamiliar with available JS frameworks and patterns find CoffeeScript an attractive alternative to acquiring new skills ( to be blunt and superficial ).
That's actually a good point, don't apologize for it. CoffeeScript is better for Rubyists, and if those who learn it then can probably be more productive using it than JS.
My personal trajectory as a developer happened to afford me Ruby development experience prior to structured javascript projects, I rather like Ruby, as I do a number of languages for varying reasons and applications.
I think you are wrong to say that 'Rubyists' could be more productive by not learning 'good' JS practices and patterns - though perhaps you meant 'be productive more quickly', even then I would have to point out that the majority of environments include legacy and 3rd party code which would likely be in 'Plain Old JavaScript' - an inability to properly understand, adapt or maintain that code would leave them at a disadvantage.
I think that statements such as "highly nested function definitions marching ever rightward" should raise a red flag - indicative more of unfamiliarity with named functions and scope binding rather than actual language deficiencies.
No, because the nested functions are closing over outer variables, typically. Manually lambda-lifting and passing extra parameters is ugly and costly, no one should do it by hand.
An assertion which I will be kind enough to only characterize as over broad
- invalidated by yourself immediately below. Approaches should be chosen based on the particular context. An application of size with an over-reliance on closure supplied variables is a recipe for a maintainability nightmare, and likely less amenable to code reuse. I am very happy that closures exist in javascript and try to put them to good use where I find it appropriate - but the very existence of closures shouldn't leave one blind of the benefits of named functions, nor ignorant of the functionality that can be afforded by context binding.
Some say nesting, those who decry it should toughen up. This ignores two problems:
- Closures can be the best, safest, most concise way to use continuation passing style, but they can bite back if too much is entrained, and you get a leak. Erik Corry's JSConf.eu talk showed examples.
I would be very surprised if people leveraging continuation passing style in JS aren't doing so for recursive functions where nesting should be fairly limited - and cycling the call stack is probably more of a practical concern.
Admittedly I haven't come across any examples of CPS for production - do you have any examples you could share that are handcrafted rather than artifacts of compilation?
TCO would seem to me to be an important first step in making CPS practical for production JS.
- Nesting to high indentation level can be annoying to write and read.
Well, yes - so don't do it? We are fortunate to have a language where you can nest function definitions, that doesn't mean that you should abuse the privilege and then complain about it.
These aren't the end of the world, but they keep coming up as real problems for many programmers.
I'll admit that in my years I have never run into a situation where I found myself forced into nesting levels that I found problematic. This could be due to a lack of exposure to situations that mandate it on my part, perhaps you could point to constructs where that is a necessity ( aside from deeply branched CPS covered above ) ?
-- Joe Developer
One issue with my minimalist writing style is that it's easy for people to imply intent that is not there and for that I apologize. This reply will be long in order to avoid misunderstanding.
I am not implying that there is a black and white distinction between people working on the language and people using it, obviously it is a spectrum which is why I was careful to phrase my comment "majority of [time spent] designing languages" and did not say "solely" or "exclusively" designing languages.
Because I know him and his work best I will focus on Brendan. I have as much respect for Brendan and his work as I probably have for anyone I've ever known professionally. Brendan does, and I doubt that anyone would be surprised, spend more of his time working on driving the language forward than he spends writing code in it. And this is for the benefit of us all and we should be grateful. There is no person I trust more with the future of the web than Brendan.
Brendan, to his credit, really does care about feedback from people using the language. For example, he puts up with me, when I've been drinking!
I have a very narrow view. I primarily program in node.js, not for the Browser(s) and I primarily care about the experience of new and intermediate programmers, not about experts. I express my opinion on this list and trust that is valued as a representation of a narrow slice of the community and not as the majority. I'm happy to lose when the solution benefits more people than I might represent or agree with.
Now, a standards body is never an even representation of a community. There is a high bar to entry and people who can afford to spend their time expressing their opinion on that standard can have an uneven representation within the standard itself. I put my faith in people like Brendan to measure the amount of feedback we have that might represent a larger portion of the user base than myself to make this a better language and not a language designed for language designers and people like me who find the time to bitch on this list.
This list has more user representation than most standards and I was only trying to encourage those who are driving this process, like Brendan, to continue to value that feedback over people who have more time to make their voice heard because it's essentially their full time job.
On Thu, Oct 13, 2011 at 6:11 AM, Juan Ignacio Dopazo <dopazo.juan at gmail.com>wrote:
On Wed, Oct 12, 2011 at 7:52 PM, Joe Developer <joe.d.developer at gmail.com>wrote:
I'll admit that in my years I have never run into a situation where I found myself forced into nesting levels that I found problematic. This could be due to a lack of exposure to situations that mandate it on my part, perhaps you could point to constructs where that is a necessity ( aside from deeply branched CPS covered above ) ?
I too write JavaScript all day and there have been very few cases in which I found myself in a callback hell. It happened mostly while writing promise-based libraries for Node (to avoid callbacks in the first place irony).
However here's an example that someone posted in this list a while ago in which it really becomes hard to read the intent due to the verbosity of "function":
www.cs.rit.edu/~ats/projects/jsm/paper.xml
Search for "eval".
Juan
On Thu, Oct 13, 2011 at 6:11 AM, Juan Ignacio Dopazo <dopazo.juan at gmail.com> wrote:
On Wed, Oct 12, 2011 at 7:52 PM, Joe Developer <joe.d.developer at gmail.com> wrote:
I'll admit that in my years I have never run into a situation where I found myself forced into nesting levels that I found problematic. This could be due to a lack of exposure to situations that mandate it on my part, perhaps you could point to constructs where that is a necessity ( aside from deeply branched CPS covered above ) ?
I too write JavaScript all day and there have been very few cases in which I found myself in a callback hell. It happened mostly while writing promise-based libraries for Node (to avoid callbacks in the first place irony).
However here's an example that someone posted in this list a while ago in which it really becomes hard to read the intent due to the verbosity of "function":
www.cs.rit.edu/~ats/projects/jsm/paper.xml
Search for "eval".
Juan
I was very close to mentioning in my response to Brendan that the first thing that came to mind regarding deep nesting and closure reliance was the context of exactly 'JS as a target for other languages' - but I was concerned that it could serve as an unnecessary distraction.
The particular example of legibility of Monadic parsers ( or indeed parsers as a whole ) doesn't strike me as particularly important in the relative scheme of things - on one hand because it is a relatively rare use case ( to put it mildly ) - on the other, because I imagine that they tend to themselves to be best suited as artifacts of code generation ( and this would hold true irrespective of nesting concerns alone ) - generated code would likely only hold interest in educational and debugging contexts of the parsers - situations where proficiency / attention-span is either a desired outcome or already acquired.
I have greater sympathy with the Promises use case - I tend to prefer events myself, which I regard as allowing greater flexibility - with the trade-off of less explicit conventions to be followed.
Event constructs could be abused to be overly reliant on closures, but I generally find little reason to - prior art endows us with a rich pattern library.
On Thu, Oct 13, 2011 at 11:18 AM, Juan Ignacio Dopazo <dopazo.juan at gmail.com
wrote:
On Thu, Oct 13, 2011 at 12:23 AM, Joe Developer <joe.d.developer at gmail.com
wrote:
I was very close to mentioning in my response to Brendan that the first thing that came to mind regarding deep nesting and closure reliance was the context of exactly 'JS as a target for other languages' - but I was concerned that it could serve as an unnecessary distraction.
The particular example of legibility of Monadic parsers ( or indeed parsers as a whole ) doesn't strike me as particularly important in the relative scheme of things - on one hand because it is a relatively rare use case ( to put it mildly ) - on the other, because I imagine that they tend to themselves to be best suited as artifacts of code generation ( and this would hold true irrespective of nesting concerns alone ) - generated code would likely only hold interest in educational and debugging contexts of the parsers - situations where proficiency / attention-span is either a desired outcome or already acquired.
I have greater sympathy with the Promises use case - I tend to prefer events myself, which I regard as allowing greater flexibility - with the trade-off of less explicit conventions to be followed.
Event constructs could be abused to be overly reliant on closures, but I generally find little reason to - prior art endows us with a rich pattern library.
I chose that example because it stayed with me because of how interesting it is and because it was brought up in es-discuss sometime ago. *Obviously *writing parsers has nothing to do with more common usages for JavaScript like UI development. The point was that there are some cases in which the verbosity of "function" gets in the way. That one is particularly noisy visually.
Still, even ignoring callback nesting, I love the prospect of arrow functions, specially for doing operations on arrays. I find array.filter((x) -> !!x).map((x) -> x * x) a lot easier to read an understand than array.filter(function(x) { return !!x }).map(function(x) { return x * x });
Juan
Whereas, in many contexts, I would much prefer ( assuming that there weren't crossbrowser concerns, and that I actually found this particular functionality attractive ): /**
- Processes an array of values, attempting to square truthy items.
- Note that item values of 0 will be excluded from the returned set and non numeric but truthy entities will yield NaN
- @param {array} arr Array of items to attempt square for truthy values
- @return {array} Resultant array from attempts at squaring truthy items in passed array.
- @testParam arr = ["not ok", -2, 3 ,4, 0, 1]
- @testReturn [NaN, 4, 9, 16, 1] */ var arraySquared = function (arr) { var result = []; arr && arr.forEach && arr.forEach( function( item ){ !!item && result.push(item * item);}); return result};
And if I wanted to be edgy and sacrifice the element of least surprise for convenience I could then do something lame :
Array.prototype._square = arraySquared; Array.prototype.square = function(){return this._square(this)}; For: ["not ok", -2, 3 ,4, 0, 1].square();
Truthfully the -> arrow construct is one that I have an aversion to which
borders ( I'll admit ) on the irrational, while it is 'pretty' and serves the aesthetic focus of coffeescript well, I have a hard time seeing the inclusion of such a construct in javascript as anything but pandering.
If anyone is seriously writing production code where 'function' is meaningful percentage of source then I would suggest that it is indicative of fundamental problems with their approach rather than the language itself. I would probably feel comfortable arguing that language designers enabling that kind of behavior are ultimately doing users a disservice.
Even accepting that "function" constitutes a significant percentage of words typed in best practice apps by the intended audience and hence could do with a shorthand alternative - which I will assume plays a part in motivations for supporting the -> construct - this particular key combo seems to require
a wider range of motion and offers much less of an improvement in typing time than the reduction of characters would seem to indicate.
-> This way to carpal tunnel syndrome
I think that better alternatives can be found, should there be a compelling net benefit at all.
As for shooting down the useful ness of -> I personally find that one line
functions are ugly.
So:
someObject.method = function () { doSomething(...); }
is ugly because it doesn't follow my { \n convention for readability and
code organization.
However I'd be happy to make an exception in my style guide for
someObject.method = () -> { doSomething(...); }
My reason for wanting -> or some other short hand is to allow an exception
in my javascript style guide for one line functions with the understanding that javascript authors don't abuse -> to make unreadable code.
Generally it's not about function being a long keyword, but about allowing a shorthand for the function keyword that makes one line functions more readable
On Thu, Oct 13, 2011 at 6:32 AM, Joe Developer <joe.d.developer at gmail.com>wrote:
Truthfully the -> arrow construct is one that I have an aversion to which borders ( I'll admit ) on the irrational
My emails where private on purpose because all those arguments where made before. Just look through the archives.
I also answered privately because I did not want to bring up arrow functions in a thread named Grawlix. I don't think they qualify. <| is very much arbitrarily chosen to look a little like an UMD inheritance arrow. -> by
contrast looks very similar to what everyone is (hopefully) taught in school when learning about functions in math, even non programmers. <| would be mostly used by abstraction makers. -> by abstraction users.
Juan
On Thu, Oct 13, 2011 at 8:39 PM, Juan Ignacio Dopazo <dopazo.juan at gmail.com>wrote:
On Thu, Oct 13, 2011 at 6:32 AM, Joe Developer <joe.d.developer at gmail.com>wrote:
Truthfully the -> arrow construct is one that I have an aversion to which borders ( I'll admit ) on the irrational
My emails where private on purpose because all those arguments where made before. Just look through the archives.
I meant nothing untoward by posting them to the thread - I initially thought that it was an oversight that they weren't in the first place.
If those arguments represent the strongest from the archives then I am surprised to read mention of nesting as an issue of interest at all.
I also answered privately because I did not want to bring up arrow functions in a thread named Grawlix. I don't think they qualify. <| is very much arbitrarily chosen to look a little like an UMD inheritance arrow. -> by contrast looks very similar to what everyone is (hopefully) taught in school when learning about functions in math, even non programmers. <| would be mostly used by abstraction makers. -> by abstraction users.
I don't think it is a particularly bad place to bring it up, btw, when I was introduced to functions it was as f(x), while -> was used in denoting limits
when x would approach a given (generally unreachable) value, see en.wikipedia.org/wiki/Limit_(mathematics) for more.
On Oct 12, 2011, at 6:52 PM, Joe Developer wrote:
On Thu, Oct 13, 2011 at 2:07 AM, Brendan Eich <brendan at mozilla.com> wrote: Why are you replying to Axel's reply to Mikeal?
My contribution to this thread was precipitated by the constellation of comments regarding JS programmer feedback - this happened to be the last post in the thread at the time and espoused the view, basically, that users of exclusively the current production environment language shouldn't have a voice in the direction of the language they will be using going forwards.
Ok. I get a bit grumpy about people exchanging messages here, with personal pronouns (so it's like they are conversing with each other), and then someone jumps in. Especially with a pseudonym. Also, want better signal to noise in es-discuss.
Who are you, anyway?
Vague and useless by some estimations, apparently. If you have specific metrics in mind for what defines a person then feel free to ask to them.
Never mind, then -- I just wondered since you did a pseudonymous interruption of a specific conversation. Who knows, you could have been Mikeal inadvertently replying from another alias.
So stay cloaked if you must. Just try to be precise and useful :-|.
Apologizing for not pointing to specific proposals holds meaning for me.
That's just noise. Make precise comments or hold your fire.
There have been comments regarding ES becoming / being "an assembler language" - making it more amenable to letting people work in languages where they are more proficient / comfortable or otherwise expect a productivity advantage.
That's a goal, one among many. They compete, and that goal is not the most important by a long shot.
While I can empathize with the abstract desire to be able to use a preferred language in lieu of something else - I have to admit that I worry about possible consequences of concessions to this goal, to be vague and useless yet again.
Balancing goals is an art, not a science. So, noted. We'll try not to screw this up.
I think you are wrong to say that 'Rubyists' could be more productive by not learning 'good' JS practices and patterns - though perhaps you meant 'be productive more quickly',
Productivity is work / time, so I meant what I wrote, and "more productive more quickly" is redundant :-P.
even then I would have to point out that the majority of environments include legacy and 3rd party code which would likely be in 'Plain Old JavaScript' - an inability to properly understand, adapt or maintain that code would leave them at a disadvantage.
Could be.
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
I think that statements such as "highly nested function definitions marching ever rightward" should raise a red flag - indicative more of unfamiliarity with named functions and scope binding rather than actual language deficiencies.
No, because the nested functions are closing over outer variables, typically. Manually lambda-lifting and passing extra parameters is ugly and costly, no one should do it by hand.
An assertion which I will be kind enough to only characterize as over broad - invalidated by yourself immediately below.
What?
Approaches should be chosen based on the particular context. An application of size with an over-reliance on closure supplied variables is a recipe for a maintainability nightmare, and likely less amenable to code reuse. I am very happy that closures exist in javascript and try to put them to good use where I find it appropriate - but the very existence of closures shouldn't leave one blind of the benefits of named functions, nor ignorant of the functionality that can be afforded by context binding.
See stackoverflow.com/questions/4234619/how-to-avoid-long-nesting-of-asynchronous-functions-in-node-js and note the first answer's "if you are accessing closure variables within the inner functions, the above would not be a straightforward translation. In such cases, using inline anonymous functions is even more preferable."
The problem people decry with nesting is not general continuation passing style, e.g., to implement a state machine. Lack of proper tail calls until ES6 makes that hard. Neil Mix's NarrativeJS had to "reset the stack" via setTimeout to avoid overflows.
Rather, the specific kind of CPSing involved is for "evented" callback programming. The nesting does not get arbitrarily deep. Often there are only one or two levels. State propagates via upvars (not properties of |this|, if you meant |this| by "context binding).
[snip]
Who are you, anyway?
Vague and useless by some estimations, apparently. If you have specific metrics in mind for what defines a person then feel free to ask to them.
Never mind, then -- I just wondered since you did a pseudonymous interruption of a specific conversation. Who knows, you could have been Mikeal inadvertently replying from another alias.
So stay cloaked if you must. Just try to be precise and useful :-|.
I've known "Joe" to go by this name in these technical forums for some time now. At what point does a name stop becoming a pseudonym and start becoming your identity? I don't believe his intent is to hide his real identity, but I can see how the overtly generic name could serve to confuse :)
[snip]
I think you are wrong to say that 'Rubyists' could be more productive by not learning 'good' JS practices and patterns - though perhaps you meant 'be productive more quickly',
Productivity is work / time, so I meant what I wrote, and "more productive more quickly" is redundant :-P.
Isn't that like saying velocity / time is redundant? You could call it work acceleration, a worthwhile metric in its own right, and I think a fair characterization of what Joe was getting at.
That said, it doesn't really matter how anyone feels about javascript as a compile target for the web. This is a reality today, and could only be undone by crippling the language. Obviously noone wants that, so what's the harm in striving to improve its utility as a compile target?
[snipped the rest]
On Oct 13, 2011, at 12:28 PM, Dean Landolt wrote:
I think you are wrong to say that 'Rubyists' could be more productive by not learning 'good' JS practices and patterns - though perhaps you meant 'be productive more quickly',
Productivity is work / time, so I meant what I wrote, and "more productive more quickly" is redundant :-P.
Isn't that like saying velocity / time is redundant? You could call it work acceleration, a worthwhile metric in its own right, and I think a fair characterization of what Joe was getting at.
I see -- good point. But productivity was what I meant. I'm not sure about any fancy second derivatives, just the first.
That said, it doesn't really matter how anyone feels about javascript as a compile target for the web. This is a reality today, and could only be undone by crippling the language. Obviously noone wants that, so what's the harm in striving to improve its utility as a compile target?
The only harm, and I think Joe expressed the worry well enough, is if we do that at the expense of any of safety (not gonna happen), crawl-walk-run learnability, or other usability notions. We talked here way back in 2006 about why call/cc (ignoring the VM implementors' problems supporting it) was overkill and a footgun for developers. But some compiler writers would love to have it.
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there real value in reforming the syntax, or is it an illusion?
I don't like C's syntax. It tastes too much like Fortran. I find Coffeescript much more to my liking. But I have found the issue of syntax to be polarizing. Some of the web developers I've been talking to love Coffeescriptish lightness. But I am doubtful that that lightness results in better productivity. Typing is not where we spend the bulk of our time.
Other web developers are getting militant about not fiddling with features that do not make them more capable at the cost of introducing portability problems. Most vocal have been people who are developing frameworks that will allow code to run in servers and browsers. Since browsers tend to lag, gratuitous syntax changes are viewed as having strictly negative value.
I think that view is rooted in the hard earned pessimism of browser wrangling. Browsers have been getting better at keeping themselves up to date. But the world is still full of IE6, IE7, IE8 and worse, and is likely to for some time.
On Thu, Oct 13, 2011 at 12:46 PM, Douglas Crockford <douglas at crockford.com>wrote:
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there real value in reforming the syntax, or is it an illusion?
I don't like C's syntax. It tastes too much like Fortran. I find Coffeescript much more to my liking. But I have found the issue of syntax to be polarizing. Some of the web developers I've been talking to love Coffeescriptish lightness. But I am doubtful that that lightness results in better productivity. Typing is not where we spend the bulk of our time.
I don't think less typing results in better typing. As you've said, typing is not the time killer. However, I think the argument could be made that if people enjoy what they're doing more, they will be more productive. This article positivesharing.com/2007/03/top-10-reasons-why-happiness-at-work-is-the-ultimate-productivity-booster/makes the claim and backs it up with some research. Is coffeescript vs. javascript big enough to be the difference between being happy or not? I think that depends on the person, but based on its popularity, I would say for some people it is.
On 10/13/2011 10:05 AM, Russell Leggett wrote:
I don't think less typing results in better typing. As you've said, typing is not the time killer. However, I think the argument could be made that if people enjoy what they're doing more, they will be more productive. This article positivesharing.com/2007/03/top-10-reasons-why-happiness-at-work-is-the-ultimate-productivity-booster makes the claim and backs it up with some research. Is coffeescript vs. javascript big enough to be the difference between being happy or not? I think that depends on the person, but based on its popularity, I would say for some people it is.
Making people productive isn't enough (having already accomplished that), we must now make them happy as well? Is that the goal now?
There are much greater sources of misery in a web developer's life than JavaScript's syntax. Let's keep some perspective.
I think our number one goal should be to not make things worse. If it is possible to also make things better, then great, but not if it means compromising our number one goal, and not if better isn't better in some observable way.
2011/10/13 Russell Leggett <russell.leggett at gmail.com>
On Thu, Oct 13, 2011 at 12:46 PM, Douglas Crockford <douglas at crockford.com
wrote:
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there real value in reforming the syntax, or is it an illusion?
I don't like C's syntax. It tastes too much like Fortran. I find Coffeescript much more to my liking. But I have found the issue of syntax to be polarizing. Some of the web developers I've been talking to love Coffeescriptish lightness. But I am doubtful that that lightness results in better productivity. Typing is not where we spend the bulk of our time.
I don't think less typing results in better typing. As you've said, typing is not the time killer. However, I think the argument could be made that if people enjoy what they're doing more, they will be more productive. This article positivesharing.com/2007/03/top-10-reasons-why-happiness-at-work-is-the-ultimate-productivity-booster/makes the claim and backs it up with some research. Is coffeescript vs. javascript big enough to be the difference between being happy or not? I think that depends on the person, but based on its popularity, I would say for some people it is.
Having tried both, I'm more inclined to JavaScript. While CoffeeScript is certainly cleaner and usually more readable -- less noises, etc --, the parser ambiguities and quirky indentation rules are terrible enough for me not to use it.
I find JavaScript's syntax already pretty light comparing with other C-family languages, mainly due to ASI.
On Oct 13, 2011, at 12:46 PM, Douglas Crockford wrote:
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there real value in reforming the syntax, or is it an illusion?
Anecdotes is all I got.
Rubyists are happier with CS and as Russell pointed out, happy helps.
Writability is not the main concern, but some do like cranking out CS. I prefer to find the smaller, but of course not the smallest, program that solves the problem I'm facing, so "cranking" is the wrong verb for how I program. Still, some extoll CS for flying off the fingers.
Readability is a better argument. I see Quildreen Motta cite some gotchas with CS, and Jeremy has told me he fixes bugs and hand-tunes the "rewriter" pass between the lexer and parser. It's a gloriously informal, ad-hoc creature. But modulo ambiguities, CS is pretty clean to read -- if you buy into significant newlines and indentation-based structure.
On Oct 13, 2011, at 10:21 AM, Brendan Eich wrote:
On Oct 13, 2011, at 12:46 PM, Douglas Crockford wrote:
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of it that way.
Syntax was the point, though, and productivity should be higher with CoffeeScript provided the user learns it, all else equal.
Do we have any evidence of that? Is there real value in reforming the syntax, or is it an illusion?
Anecdotes is all I got.
I think it's all any of us have.
In my experience, people are happiest with what they are most familiar with but they generally adapt. A lot of us Pascal (or PL/I) programmer weren't very happy when the C syntax style dominated. Lot's of organization had heated internal discussions about adopting c that essentially were nothing more than syntax debates. In the long run, none of it mattered and everybody adapted. Only in very rare case (probably COBOL and perhaps Smalltalk and Lisp) has syntax details really made a real difference in its long term adoption and ongoing use of an important language.
People coming to JS from C/C++/Java are generally happy with the JS syntax (but don't like other things about it). People coming from Ruby or Python generally aren't happy with JS syntax. In the long run, if a language like JS is highly successful it doesn't matter because ultimately most people will just learn it as one of their first programming languages.
But I am doubtful that that lightness results in better productivity. Typing is not where we spend the bulk of our time.
Good language designs tend to have light syntax (but not all light syntax languages have good designs).
The reasons have more to do with reading, and mostly with thinking about code, not just with writing.
On one side, there is code comprehension: bulky but consistent syntax can win over light but inconsistent syntax, because the surprises and exceptions hamper understanding more than the extra characters.
Many coders from bulky syntax languages are afraid of lightweight syntax, because it (a) seems to take away the guiding framework of syntax or (b) seems to require a lot of re-learning (eg, symbolic operators).
One has to realize that consistency makes for a better guiding framework than excessive syntax, and that lack of exceptions means that there isn't actually more to learn, because everything works the same way.
This step takes a bit of a leap of faith, but if the language design is truly simple/general/consistent, then those who have taken that leap are very unwilling to go back (I'm tempted to compare it to taking off the training wheels, but won't do so for fear of being misunderstood;-).
Note the importance of consistency: if the language is just a collection of shortcuts, or if there are too many unexpected corners and exceptions instead of general rules, short syntax is not going to make life any easier.
On the other side, there are our limited brains: the less we have to pay attention to LOTS OF SUPERFLUOUS SYNTAX, the more complex code we can consider at once, in terms of problem-relevant concepts we encode.
Light syntax alone doesn't improve productivity, nor do saved keypresses, but a language design that gets out of the coders' way, lets them focus on their ideas, and lets them express and hold large blocks of those ideas -in code- in their minds at once, that does. It does so by throwing fewer obstacles in the way, and light syntax tends to be one of the aspects of that process.
Claus clausreinke.github.com
This is the whole reason I love Scheme :3
2011/10/13 Claus Reinke <claus.reinke at talk21.com>
On 13/10/2011, at 19:05, Russell Leggett wrote:
Is coffeescript vs. javascript big enough to be the difference between being happy or not? I think that depends on the person, but based on its popularity, I would say for some people it is.
Based on its popularity, instead of for some people it is, I would say for most people it isn't. (I see the glass almost empty).
I would like to argue the other side. For my coffeescript vs javascript is big enough to be happy. I am happy writing javascript and coffeescript irritates me to no end.
What makes people happy is probably complex and somewhat different for different people.
I think that for many in this particular line of work it could probably be identified by 'being in the zone'. I find that it tends to accompany a sense of accomplishment, discovery by creation of value ( be it personal or as judged by stakeholders / peers ). For me personally it reminds me of "creating realities by experiencing it", or as has been mentioned in this thread "code flying from the fingers".
Which brings me to something that I was wondering about - does the ES group include / draw on any psychologists? I initially wondered about this in to 'grawlix script'.
One thing which I really like about JS relative to the ( comparatively few in present company, no doubt ) other languages I have spent time with is the relatively spartan quality of it ( "the good parts" ) coupled with the immense flexibility offered by its object and type system. A day to learn, a lifetime to master (ymmv).
The biggest impediment to me 'staying in the zone' when it comes to web programming has always been, and remains, dealing with browser idiosyncrasies and the DOM as a whole.
As has been pointed out, familiarity is important - it is the unexpected or seemingly ambiguous which can force an active conscious participation in the reading of code. It is for this reason that organizations adopt and enforce code styles, and it is in part why I think that changes to the language should need to meet a very high bar indeed.
The goals of backwards compatibility make 'enforced minimalism' very difficult - the only option is expansion, in some cases even duplication of functionality by new syntax.
I find it very difficult to shake the notion that the best solution would be found with bytecode / VM or other low-level option through which to expand available languages, preferably before too many concessions are made at the expense of JS itself.
That isn't to say that I wan't JS to live in a time capsule, but I think that emphasis should be on things which we simply can't achieve without said changes; 64 bit integers, improved handling of serialization and streaming, especially in the context of Web Workers and WebGL ( and the hopefully soon to arrive WebCL ), which would also have a measurable benefit to efforts such as Node.js .
Resolving solved problems is something we can do later.
I appreciate that standardizing existing library functionality into language standards can lead to performance optimizations - but these optimizations are, in my estimation, not going to be meaningful outside of artificial benchmarks - DOM / CSS / Canvas manipulation and repaints will continue to be the bottleneck for performance and developer effort for web applications.
On 13/10/2011, at 20:05, Allen Wirfs-Brock wrote:
People coming to JS from C/C++/Java are generally happy with the JS syntax (but don't like other things about it). People coming from Ruby or Python generally aren't happy with JS syntax.
There's many more JS/C/C++/Java programmers than Ruby/Python programmers.
In the long run, if a language like JS is highly successful it doesn't matter because ultimately most people will just learn it as one of their first programming languages.
If the objective were to serve the majority, then JS's C-like syntax should be left as is.
C remains the second most popular programming language in the world: tcrn.ch/prmhOf
JavaScript's C-like syntax is a Good Thing™
There is a word for the Beetle Bailey-inspired cursing that is formed from a sequence of special characters. It is called grawlix, a term likely coined by Mort Drucker himself.
www.typography.com/ask/showBlog.php?blogID=122