On May 11, 2011, at 7:40 AM, Garrett Smith wrote: > On 5/10/11, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: >> >> >> At a meeting today, the dichotomy we used in talking about this is the >> difference between "imperative programmers" and "abstraction builders". >> Imperative programmer know how to use basic imperative statements to >> manipulate predefined abstractions. Abstraction builders create such >> abstractions. I think that all of your #1 and much of #2 are "imperative >> programmers". While we need to continue to improve the language for this >> group we also need to start better serving the needs of the abstraction >> builders. Much of what we have promoted to proposal status seems to be >> oriented target on this latter group. >> > The mentality that "imperative programmers" and "abstraction builders" > are non-overlapping is a thinking error that pissed me off to the end > of my career as a javascript programmer.
Who said they are "non-overlapping". Obviously there is a continuum and at various times and for various tasks a single individual can be at different places along the continuum. > > Abstractions aren't to be done by the ivory tower architect (or "js > library author" or "javascript guru"). They're created out of need. > The need comes from fulfilling the requirements. I recommend Domain > Driven Design, by Eric Evans (and I have a copy for sale, in excellent > condition). I don't see where I said or implied anything about this either. Abstraction is tool for dealing with complexity. It is essential for deal with any sizable programming problem. It is a skill that has to learned. Many "imperative" programmers have not yet learned this skill and you can see it in the code they write when they try to deal with complex situations. When you sell your copy of DDD I recommend you use the proceeds to get http://wirfs-brock.com/DesignBooks.html I know Eric did. > > Please don't design Ecmascript based on categorizational false dichotomies. Different language features exist to serve different use cases. The features you need to build good abstractions are not the same feature you need to easy express sequences of imperative actions. I don't think anybody would be very happy with a language whose designers didn't make an attempt to understand various categories of users and use case and how various features relate to them. Allen
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
