Abstraction And Organizations
Abstraction And Organizations(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."
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.
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.
EditText of this page
(last edited June 12, 2013)
or FindPage with title or text search