Re: Programming language and IDE design

Martin Ward schrieb:


> If code is hard to write, then programmers will be motivated
> to spend fewer lines of code to implement a particular functionality.


A similar (or better) effect can be achieved by old batch processing,
with one compilation per day, feedback next day. This procedure leads
to *better* code, by thinking *before* writing instead of while
debugging and bug fixing.




> Similarly foolish wisdom is seen in IDEs (Integrated Development Environments)
> which allow the programmer to create hundreds of lines of code
> with just a few clicks of the mouse. Thus instantly creating a significant
> maintenance effort.


See your statement (2) below.


IMO the use of domain specific languages is good practice, and when an
IDE performs the translation of such a language into the
implementation language, I see no reason why an IDE should be able to
create much code when required. A preprocessor could do the same job,
leading to the same problem: how many languages or macros should be
used in one program? Is such domain-specific code really easy to read,
for somebody not familiar with all those languages?


In practice I can't see anything bad in automatic generation of e.g.
event handlers (Delphi forms), or replication of declarations for
implementation (2).


> Another example of this "wisdom" (which in my
> experience is very common among commercial IBM assembler
> programmers) is when a programmer needs to implement a new function
> which is fairly similar to an existing function: he or she just grabs a copy
> of the existing module, changes a few lines of code and slaps it
> into production. Over time, the two copies drift further apart,
> bugs are fixed in one copy but remain lurking in the other copy,
> new programmers have two lots of code to read, which are
> confusingly similar, and so on.


This is what I observe in one of my current projects. An attempt to
merge 4 spring-offs back into one program is a nightmare, for which I
couldn't find a solution yet. First it's hard to figure out all the tiny
differences in the copies (maybe tiny but important), and then to add
virtual methods to cover all the differences. In the end nobody will
understand the purpose of those added methods, how to prove their
correctness, and where to place further adaptations.




> So my assertion is "Source code should be hard to write": *even if*
> the writing difficulty does not result in any improvement in ease of
> reading! For example: before any programmer checks in a new module or
> program change, they should be forced to write out all the code
> longhand with a quill pen. This apparently pointless extra work
> should give programmer's the opportunity to think about whether there
> might be a shorter way to solve the problem (which might even be
> easier to read and understand).


See "batch processing" above.




> This also affects programming language design:
>
> (1) Rather than use "{" and "}" for every type of grouping, each
> different type of group such as an if statement or while loop, should
> have its own opening and closing keywords. This is something that
> modern COBOL gets right (along with the many things it gets wrong!)


True in general, but assistance of an IDE (for proper closing brackets)
would increase productivity. I'm not sure what "modern COBOL" means, but
the idea of IF...FI, DO...OD and similar bracketing is nothing new.


More verbose or less systematic brackets (IF...THEN...ELSE...ENDIF,
DO...LOOP, BEGIN...END) could be substituted by an IDE. The same for
nationalization (WENN...DANN...ANDERNFALLS...FERTIG) <shudder>




> (2) A commonly accepted rule for designing databases and software
> systems is that each piece of information should be stored in only one
> location. With a programming language, it is better for the reader if
> information is duplicated to all the places where it might be needed,
> with the compiler enforcing consistency. For example, data types and
> formal parameter names should be recorded everywhere they are needed.
> This helps the reader because the data type of a variable, for
> instance, is right there in the function where the variable is
> referenced, and the reader does not have to look it up in a different
> file.


I really don't like that, as it results in another maintenance nightmare
- unless properly supported by an IDE. Hyper links, hint popups and
multiple synchronized views (for declaration, definition, documentation
etc.) are my favorite assistants. A reader should trust the compiler,
which assures that the code is consistent, even if the source does not
have all declarations or qualifiers inlined.




> (3) Indentation helps the reader if it is consistent: so should also
> be enforced by the compiler. In line with point (2), nesting should
> be defined by *both* indentation *and* grouping keywords:
> with the compiler enforcing consistency between the representations.
> This means that the reader can rely on either indication of nesting,
> since both are reliable.


ACK


Indentation should be enforced, so that a user can e.g. view the code
expanded to his preferred tab width, without any consequential and
persistent changes to the source code.


Problematic are continuation lines, where some people prefer to continue
parameter lists on the first parameter level. This style will quickly
result in unreadable code, when nested function calls are involved.




> Comments, anyone?


IMO a language, compiler and IDE have different purposes, which you
mixed up a bit in your text. A language should allow for a compressed
and clear writeup of declarations and implementations, with a choice of
general purpose and domain specific languages. A compiler should be able
to check as much as possible, not only syntax. An IDE should assist in
both writing *and* understanding source code.




> [It's always seemed to me that the blats of code from IDEs that you
> then might twiddle are an admission that the underlying design is bad,
> and they don't understand OOP. Shouldn't those twiddles be
> subclasses, with no code at all for the stuff that doesn't change?


I'm not sure which language or IDE you have in mind. I'm quite happy
with Delphi form design and coding, where the IDE creates the skeleton
which the coder then only has to complete.


> On the other hand, having recently written a lot of python code, I've
> come around to the opinion that enforced indentation is all the grouping
> you need. -John]


+1


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.