What I expect from a programming language

by Bernd Schoeller (modified: 2012 Dec 15)

Perhaps I have just been exposed to too much Python in the recent months. But somehow, I feel like I have to express the qualities that I expect from a good programming language. Eiffel has these, most others don't.

  • Programs have to be easier to read than write: Code not only communicates a solution from a programmer to a computer. It communicates a solution to other programmers or even a future self. You never understand a problem as good as in the moment you solve it. Capture that knowledge in clean and expressive code, and it is never lost.
  • Don't allow the language to trick yourself: The language must protect us from fooling ourselves. Dangling elses allow you to see wrong control flow. Tabs and spaces cannot be distinguished, so they should carry the same meaning. A single equal sign should express equality, as we have learned in school.
  • One way to do things: Multiple ways of doing the same thing only leads to confusion. It has no benefit. Software is complex enough without thousand variations of the same logic.
  • As much static checking as possible: Static checking is good. Did you ever write a larger piece of code in one go, compiled it and it produced tons of errors? All these error would still be there, if you would not have static checking. You err much more than you think.
  • No warnings: Every error free program should be a valid program. If it is not valid, an error should be raised. If it is valid, the compiler should shut up and compile it. Warnings create noise. Noise hinders understanding.
  • Coding conventions are part of the language: Whoever thinks that a language is purely defined by "what the compiler accepts" is wrong. The job of the compiler is to translate a language into what some CPU needs for execution. A language is a culture of expressing yourself. Coding conventions are part of that culture. Syntax high-lighting and indention styles are not arbitrary.

It is a relief to express these thoughts. Now I sulk back to my job and do Python and Java.

Comments
  • Peter Gummer (11 years ago 16/12/2012)

    Great list

    A great list, Bernd.

    I'm not sure that Eiffel completely satisfies the last two expectations.

    EiffelStudio generates warnings. I'm not sure that I agree with this criterion, actually, because the warnings are useful. But I guess your point is that Java, for example, generates far more warnings ... a lot of warnings that it should be treating as errors. Whenever possible, I try to switch on the "treat warnings as errors" option if it's available for whatever compiler I'm using.

    Eiffel has coding conventions about upper- and lower-case, but it doesn't enforce them. CLASS_NAMES_ARE_SUPPOSED_TO_SHOUT_AT_YOU, for example, but the compiler will accept ClassNamesInPascalCase without complaining.

    Now get back to work ;-)

    • Bernd Schoeller (11 years ago 16/12/2012)

      Concerning your points

      Hi Peter -

      thanks for the feedback. Concerning your two points:

      In the Eiffel traditions, there should be no warning. The only exception is deprecated classes, features or language constructs. At least that is how I remember the theory. Not sure about how much EiffelStudio currently warns.

      The Eiffel compiler is not case sensitive and the language syntax does not require correct casing, but the style guides make clear statements on how to use upper- and lower-case. That was the point that I made: the compiler does not define the language culture, just what gets translated to machine code.

  • Colin Adams (11 years ago 16/12/2012)

    As much static checking as possible

    I agree with the comment, but not with the assessment that Eiffel meets it. There are languages that do FAR more static checking.

    And of course we still have the CATCALL wholes.