Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.linkpendium.com!news.linkpendium.com!news.iecc.com!.POSTED!nerds-end From: Martin Ward Newsgroups: comp.compilers Subject: Re: Programming language and IDE design Date: Thu, 7 Nov 2013 19:40:43 +0000 Organization: Compilers Central Lines: 147 Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <13-11-003@comp.compilers> References: <13-10-016@comp.compilers> <13-10-017@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: leila.iecc.com 1383878748 65784 64.57.183.58 (8 Nov 2013 02:45:48 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Fri, 8 Nov 2013 02:45:48 +0000 (UTC) Keywords: design Posted-Date: 07 Nov 2013 21:45:48 EST X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1027 BartC makes the point that the redundancy provided by enforced consistency between grouping and indentation will catch typos which would otherwise cause bugs in the code. Hans-Peter Diettrich claimed that batch processing "leads to *better* code, by thinking *before* writing instead of while debugging and bug fixing." Our esteemed moderator also noted that "Keypunching often had this salutary effect." Regarding automatic generation of code, two cases need to be distinguished: A domain specific language which is automatically translated into executable code is fine: so long as it is the DSL code which is maintained. This is a way to reduce the total amount of code for the reader to have to read, while also making it more readable: a good DSL should lead to code which is closer to the problem domain and is understandable by an expert in the domain. On the other hand, if the DSL is used to generate huge wads of code which then form part of the system to be maintained: well, that is the same as using a compiler to generate an assembler program, then throwing away the source code and maintaining the assembler. How many languages should be used in one program? As many as necessary: if they are "little languages". If they are huge, baroque monstrosities like PL/I or C++, then one of these language is already too many :-) "Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit." --E.W.Dijstra "The Humble Programmer". "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?"--Tom Cargill, C++ Journal, Fall 1990. 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. Regarding enforced indentation: with continuation lines it could be possible to slightly relax the restrictions and allow two or more indentation points to be valid. George Neuner says "My preference is simply for a common END keyword used by all constructs." This is just as bad as using "}" to close all nesting: END END END END END I want to insert a line of code at the end of the loop body which is nested in some IF statements, and contains some nested statements. Where do I put it? (The top of the loop is a few pages earlier.) Of course, you could still end up with: FI FI FI FI FI ... which is an argument for repeating the test at the closing keyword. > 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? This point raises some important issues about languages and compilers: (1) The language should be easy to parse: both for humans and computers. Just because it is *possible* to invent a new parsing technique which can unscramble almost impenetrable complexity and ambiguity, does not mean it is a good idea to define such a language. (2) Absolutely no behaviour should be "implementation dependent" or "undefined". Every syntactically valid program should have a single semantically valid meaning (even if that meaning is "halt with an error message"). (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. (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. Similarly, a string data type which can hold any size of string. Hash tables should allow any type of key and value, and so on. 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!). This means: redundancy (to catch errors at edit time), strong typing (catch errors at compile time), no aliasing (so the behaviour of a piece of code can be determined from the code alone), no unrestricted pointers, no undefined behaviour (so runtime errors can be caught at runtime). As well as the security benefits, there are also significant performance benefits from the above approach: if the language is easy to parse, then the whole program can be parsed quickly: which solves the problem of ensuring consistency between modules. If the language is also easy to analyse, then the whole program can be analysed and compiled as a unit: leading to many more optimisation possibilities. Strong typing, together with the elimination of aliasing and pointers also allows much deeper analysis and optimisation. Memory is cheap and CPUs are powerful, so whole-program analysis and optimisation should become the norm: but this provides the greatest benefit when the language is easy to analyse. Hans-Peter Diettrich 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? :-) William Clodius wrote: > Among workers whose primary task is not > programing it can be very difficult to get a mutually consistent > programming style unless their mutual inconsistencies, where it affects > legibility, have significant consequences. 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! -- Martin Dr Martin Ward STRL Principal Lecturer and Reader in Software Engineering martin@gkc.org.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4 G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/ Mirrors: http://www.gkc.org.uk and http://www.gkc.org.uk/gkc