Reported by: Mark Rosenbaum

 

Duration: ~50

 

Supplier: All platforms all languages

 

Alias: “We decided in 1944 that programming should be like doing arithmetic in Roman Numerals or even worse with the numbers spelled out in English.  Why change?”

 

Product: Every serious programming language ever invented

 

Bug: Describing logic flow in text makes programming insanely difficult

 

Class of Error: “It’s better then coding in binary or assembler.”

 

Principle: Describe the problem, not how the computer works.

 

Proposed Fix: Completely new paradigm for programming.

 

Discussion: Trying to write a program in a text-based language is like trying to do long division with Roman Numerals. It can be done but it’s very painful and error prone. Wait! Does this sound familiar? Is it possible that the entire software crisis is due to the fact we are trying to program a computer the same way we compose emails. Programs map inputs to outputs, which is the way we should think about specifying our instructions to the computer. Any more detail would violate my NDA.

 

Bug on list since: Jan 2005 

 

Bug Name:  Programming Languages

 

Reported by: Mike Howard

 

Duration: [in years] 30+

 

Supplier: Language Designers

 

Alias: Easy to use, full featured

 

Product: C,C++,perl,etc,etc

 

Bug: Programming languages are designed for parsers, not programmers

 

Class of Error: solving the wrong problem

 

Principle: Programming languages are designed to be parsed, but not read.  Considerable useless freedom is built into languages which detracts from readability by making visual clues as to a programs structure and content optional.

 

Proposed Fix: Design readability into languages.

 

Discussion:

 

It is stylish for most multi-programmer projects to compile, document, and publish a thick set of programming standards.  All of these standards are intended to make programs more readable by requiring programmers to remember to write things in consistent ways.  These cover indentation style, capitalization of various types of things, brace and parenthesis placement, etc, etc.

 

Most of the differences of opinion on these matters are arbitrary.  Any one set of standards is equal to another.

 

One example is controlling scope of looping and conditional directives.  Typically a loop begins with a key word, followed by a conditioning phrase and then a block of code delimited by start symbol and terminated by an ending symbol.  Python as demonstrated that most of these symbols are unnecessary.  Python signals the beginning of the block of code with the colon (:) which simultaneously terminates the phrase.  Each line of the block is indented at least one additional indentation character than the originating line.  The first Ôout-dent’ terminates the block.

 

e.g.

  for x in range(0,10):

    print x

  print Ôend’

 

This syntactic requirement serves two purposes: (1) succinctly defines the language constructs so it can be mechanically parsed and (2) visually displays the scope of the Ôfor’ loop.

 

This needs to extended and applied more rigorously.

 

I would suggest the following become some of the syntax rules for the next wonder-language:

 

• constants be either literal numbers or all upper case identifiers

 

• all variables begin with lower case letters

 

• Python’s statement scoping technique be used with the additional restriction that only one indentation character be added for each successive level of scope

 

• All class names begin with an uppercase letter followed by at least one lower case letterer

 

• statement terminators be abolished - except for the Ôend-of-line’ character

 

• only one style of comment be supported

 

• if possible, design the language so that there is only one way to do anything

 

• do not require Ôprogramming in the large’ constructs - such as name spaces - for all programs

 

• have reasonable defaults and provide a simple way to determine what they are

 

• make the run-time system as light weight as possible.

 

• no syntactic elements should be optional

 

• outlaw macro preprocessors

 

• everything should be an object, but the compiler/interpreter should be able to Ôfix this’ in cases where it doesn’t make sense and efficiency is significantly impaired.  The following code should work:

 

a = Ôfoo’
print a.length()
a = 1
print a.length()

 

It should not generate a run-time error.

 

Some new languages which do not go in this direction are C#.  C#, as does Java, adds additional layers of  required stuff which is probably only needed to fit into their run-time systems.  C# has added an additional embedded documentation syntax by adding yet another form of comment delimiter and embedding the comments in XML.  This is the absolute wrong way to go about this.

 

The proposed [and implemented] fix for program language complexity and obtuseness is the IDE.  This neither fixes nor simplifies the problem, but only adds and additional, complex, bug-ridden, user interface to the already difficult task of writing code in languages which are bulky and difficult to understand by design.

 

Bug first observed: Probably with the invention of Algol or C

 

Bug on list since: Jan 2005

 

Bug Name: Meaningful command names

 

Bug name (extended): Meaningful command names? pah! I can do all this with one command. Just check the 400 page manpage!

 

Reported by: Giles Constant

 

Duration: 30?

 

Supplier: AT&T, Redhat, OpenSSL.org

 

Alias: -f X -p -q YOU PUT THE X IN FRONT OF THE -p DIMWIT!!

 

Product: rpm, date, openssl, tr

 

Bug: People don’t write command line syntax which is readable or makes sense.

 

Class of Error:

 

Principle: Command line interfaces need design too! A command line program should have a syntax which is simple, concise, meaningful, and consistent in syntax with all of the other commandline programs (there’s no excuse for not using Ôgetopt’). Where space and mnemonics are limited, the most commonly used options should be the most accessible and easy to remember.

 

Proposed Fix:

 

1)      Use getopt

2)      Split commands with large numbers of functions and options into separate commands with less, easier options. 3) Use the correct and unambiguous word for each option

 

Discussion: “rpm —info ./file.rpm” should be enough information to tell rpm to describe the package infront of it. Instead it’s (quick check of man page..) “-qip”... “q” for “query”, “i” for “info”, and “p” for package [when it really means “file”], as though it’s not patently obvious that I’m referring to the file directly in front of it. It’s one of the most common operations you’re likely to use, and yet has nothing memorable about it.

 

Bug on list since: Jan 2005