Skip to main content
Post Made Community Wiki by Mr.Wizard
Added omitted word
Source Link
m_goldberg
  • 108.1k
  • 16
  • 104
  • 259

This answer is entirely opinion, but given the question, what else could it be?

I reject the OP's linear skill rating proposal. Mathematica is too large and to amorphous for the skill of its diverse user community to be categorized in such a tidy way.

I also disagree with the OP's view that code will inevitably get more concise as one's Mathematica skills increase. One does get better at playing code golf, but for serious projects -- say writing a Mathematica package intended to be used by many people over many years -- the need to support argument validation, manage options, supply meaningful error and usage messages, support unit and functional-level testing, etc., all conspire to bloat the code far above the conciseness that can be achieved when one doesn't need to worry about such things, such as when answering questions of this site. That is, for many "real-life applications", the need to do software engineering overrides the aesthetics of concise coding.

This answer is entirely opinion, but given the question, what else could it be?

I reject the OP's linear skill rating proposal. Mathematica is too large and to amorphous for the skill of its diverse user community to be categorized in such a tidy way.

I also disagree with the OP's view that code will inevitably get more concise as one's Mathematica skills increase. One does get better at playing code golf, but for serious projects -- say writing a Mathematica package intended to be used many people over many years -- the need to support argument validation, manage options, supply meaningful error and usage messages, support unit and functional-level testing, etc., all conspire to bloat the code far above the conciseness that can be achieved when one doesn't need to worry about such things, such as when answering questions of this site. That is, for many "real-life applications", the need to do software engineering overrides the aesthetics of concise coding.

This answer is entirely opinion, but given the question, what else could it be?

I reject the OP's linear skill rating proposal. Mathematica is too large and to amorphous for the skill of its diverse user community to be categorized in such a tidy way.

I also disagree with the OP's view that code will inevitably get more concise as one's Mathematica skills increase. One does get better at playing code golf, but for serious projects -- say writing a Mathematica package intended to be used by many people over many years -- the need to support argument validation, manage options, supply meaningful error and usage messages, support unit and functional-level testing, etc., all conspire to bloat the code far above the conciseness that can be achieved when one doesn't need to worry about such things, such as when answering questions of this site. That is, for many "real-life applications", the need to do software engineering overrides the aesthetics of concise coding.

Source Link
m_goldberg
  • 108.1k
  • 16
  • 104
  • 259

This answer is entirely opinion, but given the question, what else could it be?

I reject the OP's linear skill rating proposal. Mathematica is too large and to amorphous for the skill of its diverse user community to be categorized in such a tidy way.

I also disagree with the OP's view that code will inevitably get more concise as one's Mathematica skills increase. One does get better at playing code golf, but for serious projects -- say writing a Mathematica package intended to be used many people over many years -- the need to support argument validation, manage options, supply meaningful error and usage messages, support unit and functional-level testing, etc., all conspire to bloat the code far above the conciseness that can be achieved when one doesn't need to worry about such things, such as when answering questions of this site. That is, for many "real-life applications", the need to do software engineering overrides the aesthetics of concise coding.