Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Saturday February 09, 2008
03:12 PM

Syntax is Still Not the Prime Factor of Maintainability

[ #35625 ]

If choice of syntax were the main factor of the maintainability of existing code, wouldn't the comment mantra be "Comment what you're doing, not why"?

You can look up syntax in the language's documentation.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • As human beings we're used to lists of things to do in order. Mums teach us from an early age to do X and then Y and then Z. I'm fairly convinced this is ingrained in our psyche.

    This is why the majority of people think that a + b makes more sense than + a b. It's also why procedural code is easier to understand than declarative and functional code.

    We're also taught maths from an early age, including the symbols therein, and this made Kurila's decision to rename to + seem foolish.

    So it's not quite as simple
    • Edit: this made Kurila's decision to rename < and > to +< and +> seem foolish.
    • The 1 + 1 thing, and x = y + z thing all speak to intuitiveness.

      Intuition is relative, it's the the delta between what you already know, and what else you need to know to use something.

      1 + 1 is intuitive to anyone that has done primary/grade school math.

      x = y + z is intuitive to anyone that has done high school math. The fact there is an assignment involved there is a minor delta.

      Doing things in order, and modelling reality into structures (objects) with names both also fit pretty well into the way we think
      • Instead of "intuitive", how about "familiar"? The latter actually means something in the context of computers. (I think you may mean "discoverable" in a couple of places as well; x = x + 1 doesn't fit my understanding of algebra.)

        • x = x + 1 doesn't fit my understanding of algebra.

          I guess it's because it's a different operation than the one in algebra, which is a "comparison equal" (like ==) rather than a "assignment equal".

          For the maintainability question, I imagine that it depends somewhat on the particular project. Like if were writing code for a Mars rover I would probably be interested in different aspects of "maintainability" than if I were writing a script to filter out duplicate porn.

          Maintainability would also depending on the experiences of those maintaining the code. I

          • For the maintainability question, I imagine that it depends somewhat on the particular project.

            Thus I assert that coding standards, the use of domain concepts for design, and similar organizational concepts affect maintainability more than a particular language syntax. (The debate gets fuzzier when you talk about language idioms -- Haskell's fetish for using single-letter variable names doesn't entirely lend to naming clarity, and PHP's long-fought insistence on register_globals invoked magical effects

        • But why then Perl6? All perl5 hackers are familiar with the peculiarities of perl5 and they are hopefully familiar with documenting their source code. So why a new programming language that is overly complex? (w.r.t. maintainability)
          • So why a new programming language that is overly complex? (w.r.t. maintainability)

            Who says it's overly complex? What is sufficient complexity in a programming language anyway? (Be careful answering this one. There's a waterbed in it.)

            If you take my mention of the word "learnability" as suggesting that I believe that that's an important concern to the design of a programming language... well, you're misinterpreting what I wrote, and you're in danger of falling into the seductive idea that "learnabil