Re: Programming language and IDE design

George Neuner schrieb:


> Cut-n-paste doesn't worry me so much as the decline of design and
> development skills. The average software developer today has little
> or no CS or CE education, and often little experience in the domain of
> the application.


Did you ever find a person mastering both areas?


> Combined with easy access to great volumes of open
> source code that they understand poorly or not at all, I consider the
> majority of these people to be highly dangerous. IMNSHO, a lot of
> "professional" software developers would be doing a world a favor by
> finding another profession.


ROTFL - well spoken :-]




> I despise stupid keyword reversal closings such as IF..FI - loop can
> go jump in the pool and tceles sounds to me like a high speed train
> (and probably is a homophone for a swear word in some language).


It's CASE..ESAC :-)




> Things like <keyword>..END<keyword> get unwieldy when keyword phrases
> may contain optional attributes, such as in generalized loop
> constructs where the demarcation keywords may have to include labels
> and/or conditions.


Such verbosity can help the reader in untying long and deeply nested
constructs. But in most such cases a repetition of the starting
condition or loop variable is a must.


In such situations a folding editor is extremely helpful, which can hide
all the code of an block, or the optional attributes of a loop. It also
could display the documentation of an code block, instead of the code
itself - kind of assisted Literate Programming.


> My preference is simply for a common END keyword used by all
> constructs. I think keyword case consistency is important, but I think
> the choice to use all upper or all lower should be left to the
> programmer.


I'm still waiting for the first Chinese programming language, case
insensitive, unambiguous and easy to parse due to the use of keyword
symbols (tokens), kind of AcPL. Translations into the preferred
representation of every reader would not be hard to add, even for RTL or
TTB reading. Remains the problem of identifiers, how could these be made
language neutral?






> What actually *is* important is not the choice of keywords, scope
> markers or other punctuation, but rather that the scope of control
> constructs is defined to be a list of statements. Given this,
> indentation by a structural editor will immediately show structural
> mistakes as misaligned statements.
> [For an example, look at Lisp code using Emacs "lisp mode". Try
> adding or removing a parenthesis somewhere and see what happens.]


Right, see above.


>> (2) A commonly accepted rule for designing databases and software
>> systems is that each piece of information should be stored in only one
>> location.
>
> Singleton data doesn't prevent name aliasing, in databases or in
> programs. It is the aliasing which is a major source of programming
> errors.
>
> Moreover, there is data for which multiple instances are
> indistinguishable in use, e.g., the integer value 42. Non-shared uses
> of such data can use copies interchangeably.


I like OPL enums and sets for a disambiguation, by named and typed
constants.




>> 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.
>
> Yes and no.
>
> Redundancy is good to a point beyond which it becomes noise.
>
> I prefer to define things in one place and to have the compiler
> propagate the information to wherever it is needed. Excepting
> interfaces to "foreign" objects which otherwise would be unknown to
> the compiler, I consider the redundant declarations required by many
> languages to be error-prone unnecessary crap.


+1


> How exactly should a compiler "enforce consistency" of corresponding
> declarations in separate compilation units? How is the compiler even
> to know that they should be corresponding?


Plus: how should a compiler know that some declaration or code is an
*intentional* modification? An IDE should allow to e.g. list all
implementations of a virtual method.




> Under NO circumstances should a compiler be enforcing coding styles.


This is what I'd assign to the tasks of an IDE. Not by reformatting the
source code, but by a consistent and user defined representation and
according editing features.


*Uncontrolled*
> Significant indentation is the dumbest idea since paper tape.




> Ergonomics dictates that the screen dimensions, fonts and indentation
> units that I choose for my viewing comfort should have absolutely no
> effect on your choices.


I'd extend that to the vertical axis (folding), maybe in more dimensions
    for touch screeens and other newer technologies.




> Indentation does aid human readers and should be applied consistently
> .... by means of a structural editor. Given a properly designed
> language in which control constructs expect a demarcated list of
> statements, then matching scopes will have matching indentation and
> structural mistakes in the code will be apparent due to statement
> misalignments


I'd go one or more steps further. My experience with decompilers and
translators revealed that most code can be represented in various
programming languages, not only the original one. E.g. assembly code,
from the time where restricted languages or compilers suggested to write
library code in assembly, could be translated frequently into well
structured high-level code. Maybe a result of manually tweaked compiler
output, but I doubt that.


I also could find tons of errors in prominent C code (official
examples...), by using an better compiler or by translating the code
into C++ or OPL. IMO it were really helpful to have a chance to add
semantic attributes (strong types...) to some source code, checkable by
a compiler or dedicated tool - remember lint? This would not necessarily
prevent reading and compiling a lean and mean auto-generated C version
of that code. The only practical problem is the continued development of
the uncheckable C code, whereby all added safety attributes will get
lost soon.


This might become the domain of another class of tools, which decompile
applications or libraries into structured (meta?) code, which can be
matched better with older revisions of the attributed code, so that the
modifications can be incorporated automatically into that code. In an
first step a unified representation of the compiler's parse tree could
be used for the meta language, as it reduces considerably the analysis
of final compiled binary or ASM code. This would be not so hard with
open source compilers (gcc), but the language deviations of some
(Microsoft in detail, or ObjectiveC...) compilers suggest to implement
an highly configurable parser. At least my first C decompiler could
handle compiler and linker specifics of a considerable number of C (and
BASIC) compilers and platforms (Atari, Amiga, HP-UX...), and my ToPas
translator handles source code written for GNU, Microsoft and Borland C
compilers.


It turned out soon that C is the most ugly and pretentious language WRT
to automatic analysis, that's why I continued research and
implementation on just that language. Newer languages should be much
easier to master automatically, provided that a common meta language can
be defined for the different declarations and control structures. So I
hope to end up now with something more on-topic than C bashing ;-)


DoDi

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