Re: Programming language and IDE design

Martin Ward schrieb:


> Hans-Peter describes the idea of recording variable types
> everywhere as "another maintenance nightmare": but with proper
> tool support it does not have to be. Even without tool support:
> forcing the programmer who wants to change the type of a data
> item to at least glance at all the modules which use that data
> could be beneficial.


Just to clarify my understanding and use of an IDE:


I use an IDE as a tool that tells me *more* about the source code than
it contains literally. Other people prefer to work offline, where a
small window on screen or a printed page should contain all essential
information - but do these people really need or even use an IDE?


I also don't like the way how many IDEs limit their single source code
pane to postcard size, surrounded by many toolbars and views of other
items. Often I need three or more parallel views on different parts of
a project, related to some item. Just like many printouts can be
arranged on an physical desktop, an IDE should allow for the same on
(multiple) monitors.




> (3) The language should be easy to analyse. Current program
> analysis sometimes feels like a race between researchers developing
> ever more sophisticated analysis techniques, and language
> designers adding ever more impenetrable features to the language.
> Currently, the language designers are winning: for example,
> in C++ it is a non-computable problem just to determine which piece
> of code will be executed at runtime for a given function call.


That's the advantage and price of OOP!


To me it's essential that I can split a problem into dedicated objects
(classes), of significantly lower complexity and limited dependencies.
Every object has a slim interface (public methods), nothing more is
required to understand the role and use of that object in the rest of
the code.


Of course virtual methods and heritage make it impossible to know which
exact incarnation of an object is used in a specific place of the entire
program. That's where a tool (IDE) is required to shed some light on the
internals, but not normally to understand what's going on at this place
behind the scene, moreoften instead for understanding special situations
where a specific object is used and must react in the right way.




> (4) The language should not impose arbitrary limitations on the programmer.
> An integer data type should be available and efficiently implemented
> which can hold any size of integers.


ACK


> Similarly, a string data type
> which can hold any size of string.


While I strongly agree that a string type is an absolute must, string
handling and text processing can be considered subject to a domain
specific language. At least it turned out that string operators look
nice in code, but tend to result in poor runtime behaviour (.NET) or
obscure runtime errors (Java), or both.


String handling also should be separated in multiple levels of
abstraction. The lowest level covers the allocation and operations on
physical storage elements (bytes/codepoints), and precautions against
out-of-bounds references. The next higher level deals with characters
and allows to work easily with MBCS. In fact no character type should be
used herefore, even UCS-4 does not allow to deal with fixed-size
characters (ligatures...)!


The next higher level(s) cover language/culture specific aspects of
textual information. The right name herefore would be *text* processing,
as opposed to more physical string handling (concatenation...). Casing
and sorting (comparison...) are commonly used operations at this level,
even if ASCII users often don't understand that these are not trivial
operations in foreign countries. The same for parsing and decomposition
of non-ASCII texts, such operations should be reserved for the
implementation of text processing programs (document editors...). IMO.




> Hash tables should allow
> any type of key and value, and so on.


I'd consider hash tables as domain specific, together with databases and
other containers. As opposed to strings, such items should be part of
libraries, be language specific or third-party.




> One aim is to catch errors as early as possible: syntactic errors
> can be caught at editing time (with a syntax-aware editor),
> semantic errors can be caught at compile time, and as a last resort,
> runtime errors are caught at runtime (and do not result in potentially
> exploitable undefined behaviour!).


Means for Structured Exception Handling should be part of every
language, easily usable so that nobody would ever revert to using less
safe means for error handling.




> Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>> 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...
>
> Newer languages like C++, for example? :-)


C++ suffers from two diseases: compatibility and competition ;-)


The first means syntactic and semantic compatibility to C, so that the
newly introduced good language features can be (and often are)
circumvented in real world code. Next comes execution speed, which
should not be lower than equivalent C code, what typically means that
additional safety checks are omitted from the standard libraries. And
finally C++ comes in so many incompatible flavours, that it is not
usable for platform independent projects. IMO Java is the only usable C
spring off, which is said to only look like C, but is something very
different underneath. .NET instead is still under construction, and
only works on MS supported platforms; this certainly is a design goal,
so that no cure should be expected. Some people say the same about C++,
which had to be as complicated as possible, to ensure Bjarne's long term
living :-]






> Indeed: a consistent coding style is much more important than anyone's
> personal preference: in the sense that readability is improved when everyone
> is forced to use the same style (even if some think that it is sub-optimal)
> compared to the mix of styles that results when everyone is allowed
> to write in their own way. Not to mention the wasted effort when
> people keep on restructuring each other's code into their preferred style!


Style and fashion is a matter of taste, subject to frequent change and
personal preferences. IMO we simply should accept this human component
as given, and leave it to an IDE to bridge the gap between formal syntax
and human diversity. HTML (XML...) is an example of a language that can
be used either at low level, or in a WYSIWIG presentation. The only
requirement is a standardized low level representation of a language,
which can be presented and edited in a variety of textual or more
graphical formats.


What's so bad with different representations of a program/project, with
e.g. a graphical (dependency...) view for easy overview and navigation,
and more or less abstract levels on the road down to concrete source code?


Every (event driven) GUI program requires dedicated (domain specific)
presentations of its visual components. It doesn't make sense to me when
such presentation and editing capabilities are prevented by a formal
programming language. The same for databases or other non-visual
components, which have their own interface, relationship and use in a
program. An IDE *Integrates* such views end editors, for aspect/domain
specific *Development* of parts of a project.


DoDi

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