Interesting arguments from your boss, Ovid, but a couple of rebuttals spring readily to mind.
The company I'm now working for is pretty much in commercial startup, although it's been developed for the last 7 or 8 years as a voluntary basis.
The upshot of this voluntary system is that there is now 7 years of legacy code.
At the time, it was the 'simplest thing' to get all the coders to use what they felt was the simplest thing to understand. Which worked for quite a few years.
However, now the system is being looked at in the light of being expandable and efficient, huge holes have appeared.
The simplest solution could only be expanded to do so much. There are now requirements that simply cannot be done in any even reasonably efficient manner, and now the whole thing needs to be redone from scratch (using a hybrid of Perl and C, with the whole thing being prototyped in Perl).
Applying to the wider world (the team I work with also have the concensus that this is true from past experience), you have the options of having a shortsighted or long term solution to a problem.
The shortsighted says: We want people to operate NOW. We don't want to have to train them. We will use the lowest common denominator as the default level.
Often, using the simplest thing to understand quickly also goes hand in hand with very quickly reaching the ceiling of what is possible with that tool. Once that level is reached, further optimisations/advanced techniques are denied, without a ridiculous level of learning and technical knowledge, which is obtained by very very few.
Using something slightly more difficult will have maybe a few weeks discrepancy in being operational at the simple level of coding (you're not going to be throwing in your newly trained coders to do your most sensitive programming tasks are you??). Once this initial concept is assimilated, the path from the simple coding to the very advanced is very smooth, with the ceiling of possibilities being much higher, resulting in the mid to long term of all your coders (resource to a company) being far more efficient and valuable.
So, the choice is a matter of scope. You can have the 'instant gratification' with little long term payoff, or invest a little, and be prepared to wait a very short time, and have a high long term payoff.
It seems that your company is going for the instant gratification method, and are thus, in the long term, limiting themselves.


As a rebuttal to the second point (I have 21 years programming experience):
There is ALWAYS more than one way to do it. It's not indoctrination, it's just the nature of programming.
Given a task, different people will abstract the task away in a different manner, resulting in different implementations.
That is just the way it is. It's not a Perl thing (although it's firmly stated in perl and allowed for).
This is why Software Engineering was developed. That way, the 'more than one way to do it' for the system as a whole is removed. There is one way to do the whole thing.
Interfaces are specified, internal tasks are handled in a specific way, and, in a well engineered system, the components are such that you can hand a task to a coder, and say 'this is what goes in, this is what comes out'.
To be frank, you don't really care what method of implementation they use. You just want it to be fast, stable and efficient to the best of their abilities.
In any language, the expert should code this in a different way to the novice. If that is not the case, then the expert is being artificially constrained, and years of experience in a company are wasted. They learn nothing, and the enhancement possibilities are wasted.
The joy of the engineered system is that the component may be revisited in a future version, and enhanced with new knowledge gained by the coders to be more efficient and faster, while ensuring that the entity behaves as it should within the system as a whole. Over time, this can have a huge beneficial effect.
So, in summation of this, the statement of flexible programmers being harder to manage to standards is a complete fallacy. In an efficiently managed environment, the flexibility of the coders is a boon, rather than a bane.
If coder flexibility is a general problem, then the problem is more management laziness (hey, he's PAID to do the management to the best of his ability, not take the 'easy options' and cut corners to make his day easier) and lack of engineering/standards as a whole.
Where there is a well defined problem/task, teams of very different people will reach a highly integrated solution. If the task is not well defined, then you're just looking for trouble no matter what language you use.

Just some thoughts,

Malk.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.