(Discussion Moved from GreatLispWar)

I've seen organizations complain even about "excessive function usage" with old-fashioned functions because some developers in the past were confused by the level of factoring used and they didn't want to fire them because they otherwise did decent work under lower abstraction, and often had better people skills than the "high brow" developers. (Perhaps they were partying in college while the gurus were writing compilers.) I've seen this phenomenon in multiple organizations.

Duplication rarely gets somebody outright stuck, it's just more busy work and perhaps more little bugs caused by missing one of the repeating segments accidentally. However, heavy abstraction can get developers outright stuck. '''Businesses often value consistency more than average higher productivity.'''

''Organizations that complain about "excessive function usage" are clearly dysfunctional.  In terms of language design, why cater to dysfunctional companies at the expensive of functional ones?  Dysfunctional companies are uncompetitive, and guaranteed to eventually fail when other companies -- equal in every way, perhaps, but with a more capable IT department -- will successfully compete with them.  Isn't it better (again, in terms of language design) to help the strong and capable companies get stronger, rather than let the weak ones stay weak?''

There's no study that establishes such a relationship. In fact, it seems to be the opposite in my observation: the larger the organization (meaning successful), the more likely they are to want a generic mid-range kind of programmer who follows shop conventions closely and doesn't make waves. And an Abstraction Jihad to overhaul corporate culture is a different topic altogether. I made my case about factoring and they decided otherwise. '''They were happy with the work of their programmers under lower factoring''' but not working with the higher factoring that I and prior consultants attempted. What else am I going to tell them? Fire them all and hire higher-abstraction gurus to replace them? First it would have to be demonstrated that such was significantly better for the organization. Claiming it is not sufficient. They would probably have to pay them more and spend more time screening them such that they want solid justification for the switch. And they valued domain skills/knowledge and people skills in their programmers, not just coding. Higher abstraction gurus tend to have lower people skills.

''Shop conventions are the appropriate approach to limiting features that the bosses don't want used.  Excluding higher-order facilities from languages is '''not''' the solution.''

I have to disagree with that assessment. Bosses often don't care as long as the techniques used don't cause noticeable problems.

''If shop conventions limit use of unacceptable techniques -- much as various shops forbid the use of C++ templates or multiple inheritance -- what's the problem?  Shops that don't want higher-order abstractions can forbid them.  Shops that want higher-order abstractions can use them.  100% of development shops are thus satisfied.  If, however, you don't allow higher-order abstractions in languages, then the shops that don't want higher-order abstractions can't have them.  That's fine, but the shops that want higher-order abstractions can't have them either.  Thus, only 50% of development shops are satisfied.  The latter sounds like a commercially undesirable approach for the language maker, if nothing else.''

Objects are usually good enough to approximate them. Almost no CBA app will need a high volume of HOF's to make a real difference. No language has everything a shop wants, and those that do are too open-ended, like Lisp, creating the GreatLispWar.

''GOTOs are usually good enough to approximate 'while' loops.  Is good enough, good enough?  As for what a "CBA app" will require, is it reasonable to limit a general purpose language on the basis of one domain?''

GOTO's compared with blocks are so very different as to make the analogy difficult.

''Not at all.  It's all a question of level of abstraction.  You appear to advocate a "right" level of abstraction, rather than a "highest possible" level of abstraction.  Your advocacy appears to be predicated on several myths: (1) that higher abstraction is more difficult; (2) that providing higher abstractions inherently leads to confusion when, obviously (and at worst), it is possible simply not to use them; and (3) the "right" level of abstraction is apparently precisely that provided by certain popular procedural languages of the mid to late 1980s.''

Going from level D to level C is different than going from level B to level A just like going from a motorized scooter to a car is different than going from a car to an airplane. And it's NOT a matter of "simply ignore them if you don't like them" because some will use them, perhaps without approval, and the code will become scattered with their use, most of it okay, but some of it questionable and/or confusing to other maintainers.

And blocks were road-tested before the industry felt comfortable with them over GOTO's. HOF's haven't passed, partly because objects are more familiar and can pretty much do the same thing.

[Higher-order functions have been significantly road-tested, especially in JavaScript. -DavidMcLean]

I don't know very many developers who are happy with JS in the HtmlStack; but there's not a lot of actual choice. You follow the patterns of the examples and docs and hope it works. Why some groupings are specified with parentheses, some with curly braces, some with square brackets, some with pipes, etc. often has no obvious rhyme or reason accept to the implementer. It's like encountering a new bureaucracy: "You have to fill out form X before you fill out Y because that's just the rules. And mail forms A, C and Q to address R and forms B, D and K to address S because that's the rules. Our rules."

* [Pipes? Pipes mean "or" in JavaScript. They aren't used for grouping. Parentheses are used in the same ways they are in the vast majority of languages: either to denote precedence, as in 3 * (5 + 4), or to call functions, with or without arguments, as in f() or f(x). They also appear on the conditions of if and while blocks, because JS was forced to steal those syntax aspects from Java. Curly braces have exactly two distinct meanings in JS: They either indicate an object literal, such as {x: 5, y: "somestring"}, or a block of code, such as if (somecondition) {the block in here} or function(arguments) {the block in here}. Each of these things is used in only a few, entirely consistent ways, and the vast majority of syntax will be familiar to many developers because it's copied from JavaLanguage and CeeLanguage. (The only unique bit is {x: 5} object literals, because Java doesn't have those.) -DavidMcLean]

* [If giving multiple meanings to grouping symbols, most of which are entirely consistent with a slew of other languages, bothers you, there again is CoffeeScript. In CoffeeScript, curly braces can ''only'' indicate object literals, never code blocks. Parentheses are only necessary to denote precedence, not call functions, and if and while blocks don't require them either. -DavidMcLean]

{I've been pretty happy with JS on the HtmlStack, but it does help to have clear cut decisions about what features of the language you will and won't use. Having something around like "JavaScript: The Good Parts" goes a long way toward establishing such conventions. Also spending a lot of time working with plain old JavaScript before using JayQuery or the like makes a lot of difference.} -- JeremyAube

That's right, a relatively big learning curve. GUI's have been in the market for around 25 years and GUI idioms should be pre-packaged by now to make it far closer to paint-by-numbers instead of {}${({];{};[(]};])}).fuck('this').shit.

[CoffeeScript, which I've mentioned several times, is notable for narrowing down JavaScript to The Good Parts. In combination with JayQuery, interface scripting in CoffeeScript is pretty intuitive. Typing out a huge string of random punctuation that's not actually what you'd use in any real script is a strawman, by the way. -DavidMcLean]

It's not the client-side standard so far.

[It doesn't need to be. Just use it, if you like it. -DavidMcLean]

No, maintenance of existing software is about 70% of all programming. Your suggestion doesn't scale.

[If you're incapable of tolerating JavaScript's syntax enough to maintain code written in it, convert the code to CoffeeScript first. -DavidMcLean]

Are you serious? Still, that's the boss's call usually.

* ''You're not the boss?  I think any discussion here about programming choices must presume you're the one making the choices.  Otherwise, call your boss in -- we'll discuss this with her.''

* There's a big distinction between changing a shop and changing the world. For example, an assumption that the reader can change the general nature of the talent pool is not realistic. Or even overhauling the hiring and salary practices of your own HR department.

[I'm only serious if you are. If you're suggesting JavaScript's syntax is too awful to maintain, then yes, you should change the code over. However, in most cases it's not, and there's nothing keeping you from using CoffeeScript for new projects or modules. -DavidMcLean]

Asking for recruits who know CoffeeScript limits an org's hiring options, making it harder to find maintainers who also fit other needs of the org. If it becomes wide-spread enough, that may change, but that's a pivot-able assumption.

''Asking for recruits to know CoffeeScript is the mediocre organisation's strategy.  Instead, asking for appropriate education (including good grades), related experience, interest, and a demonstrated ability to learn and adapt to new technology is far more likely to be successful.  You want the right aptitude; specific language knowledge is immaterial, inevitably soon to be obsolete, and not indicative of actual skills.''

I think we've had this conversation before. There are a lot of varied skills that an organization wants (tech, people, and domain being the primary categories). It's likely not possible to hire "A" and "B" skills in all categories, and many organizations don't want to pay for candidates that score high in all categories, and/or have existing employees that must be made to fit new positions barring major and objective deficiencies. (IT department's pay desires often don't align with HR's, and the salary rules in larger orgs can be arcane.) You cannot get a Cadillac at Chevy prices. I've been told more than once that I had sufficient technology skills but lacked "people skills" for the position, for example, despite trying to improve in that area. People skills matter to most orgs.

And again, there is the "replacement factor". Even if you can find a top-notch developer for one generation, getting another top-notch or well-fitting developer when he/she moves on may not always be easy. For this reason, orgs want code that allows for fungible staff.

Further, the manager(s) making the hiring decisions are not always the most technically adept, often because they came up through the domain ranks instead of technical ranks, and may value knowledge in existing tools/languages/techniques '''over a flexible learner'''. I see this complaint a lot. The "safe bet" for the org is to test for the shop's here-and-now skills because that can be objectively measured, or at least more easily measured because there are skilled evaluators of such topics in the org. Yes, it's a form of SovietShoeFactoryPrinciple, but life is not always fair. Maybe you personally know how to filter for such, but such advice does not scale to a good portion of typical organizations. You have to put yourself in their shoes. You can't always AssumeCanOpener.