Top 10 Language Constructs (Modula2) 
Author Message
 Top 10 Language Constructs (Modula2)

What do you think are the top ten language constructs in Modula2?
Please don't answer in terms of concepts, but try to restrict
yourself to those statements you really use to cope with your
daily work.

Curious why I'm asking this question? In spite of all requirements
engineering effort we know exactly *how* to solve problems
with computer languages but know fairly, *what* we're doing
during this process.

Regards
Bruno Gustavs



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

> What do you think are the top ten language constructs in Modula2?

You would get a better answer to this question by running a keyword
analysis of a few large M2 packages rather than asking people for their
subjective opinions.

Quote:
> Curious why I'm asking this question? In spite of all requirements
> engineering effort we know exactly *how* to solve problems

Hmm! I have seen too many problems that start out ill posed or with
hidden assumptions to begin with and the "solution" developed is not
always the solution to the true requirements of the client. (even when
they have signed off the SFRS as a true statement of their needs).
These problems are language independent, and are a major source of
project failures.

Comparatively few people know how to write clear unambiguous
requirements specs readable and understandable by both client and
developers.

Quote:
> with computer languages but know fairly, *what* we're doing during
> this process.

The *what* stage is fairly mechanical. NS diagrams can be translated
into M2.
There once was a graphical tool for doing it (reversibly) whatever
became of it ?

Perhaps I have misunderstood your point...

Regards,
Martin Brown



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:
> Hmm! I have seen too many problems that start out ill posed or with
> hidden assumptions to begin with and the "solution" developed is not
> always the solution to the true requirements of the client. (even when
> they have signed off the SFRS as a true statement of their needs).
> These problems are language independent, and are a major source of
> project failures.
...
> Comparatively few people know how to write clear unambiguous
> requirements specs readable and understandable by both client and
> developers.
...
> Perhaps I have misunderstood your point...

Lets assume you're going to design Modula17. What would this
language contain? What should Modula17 support? What would you
like to solve with Modula17?

Regards
Bruno Gustavs



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:


>> Perhaps I have misunderstood your point...
> Lets assume you're going to design Modula17. What would this
> language contain? What should Modula17 support? What would you
> like to solve with Modula17?

I think you've put the cart before the horse.  You don't decide to
invent a new computer program language and then determine what problems
it's supposed to solve.  On the contrary, one starts with the problems
that you want to  solve and then work from there to the language
intended to solve them.

Perhaps if we had a Modula-16, then there would be discussions about the
weaknesses of that language and that would (perhaps) be used as the basis
for a new langauge.

But I doubt it.

As Mr. Brown pointed out in his message, (and now I'm sorry I deleted
that part,) most of the difficulties in producing a correct program are
not the result of the design of the programming language used to
implement the program.  It is genuinely difficult to produce a correct
program if its requirements aren't well understood.

That means that most of the effort in making programming better is spent
debugging the process of programming, not trying to design yet another
language that will (really and truly, for sure this time!) eliminate any
chance of any programmer writing an incorrect program.  It also means
that the effort to improve programming SHOULD spend more effort
debugging the process.



Tue, 31 Dec 2002 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:
> As Mr. Brown pointed out in his message, (and now I'm sorry I deleted
> that part,) most of the difficulties in producing a correct program are
> not the result of the design of the programming language used to
> implement the program.  It is genuinely difficult to produce a correct
> program if its requirements aren't well understood.

> That means that most of the effort in making programming better is spent
> debugging the process of programming, not trying to design yet another
> language that will (really and truly, for sure this time!) eliminate any
> chance of any programmer writing an incorrect program.  It also means
> that the effort to improve programming SHOULD spend more effort
> debugging the process.

Thanks! Thats what i'm intrested in. See if I ask for concepts, I get
mirror of actual discussions in the corresponding journals. So I tried
to find out, how you use Modula2 to get an idea of what you are doing.

Regards
Bruno Gustavs



Fri, 03 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)
I have been working on my own language, a successor to Modula-2, for
several years.  I am well along,
but have yet to solve a few major problems. If I am successful, it will
be a major step forward, as the greatest
difficulties in programming will be eliminated.

The constructs most often used in the type of interactive graphics based
programs I write are:

1)  draw something on the screen
2)  keep lists (arrays of records)
3)  look for things in lists
4)  add, delete, and modify the list contents
5)  save the lists to the hard disk, and read them back in
6)  convert data from one format to another

For basic Windows and Macintosh programming, Modula-2 has proven to be
an excellent language; clean, simple, and more readable than another
language in existence.  However, the problems that I see unresolved in
the language are:

1) inability to detect undefined variables
2) lack of fail-soft arithmetic (like spreadsheets)
3) inability to directly model common peripherals, such as video
screens, sound chips, 3D cards
4) lack of automatic order of computation (like spreadsheets)

In most respects, conventional computer languages have lagged behind the
tools available in spreadsheets.  By number of people programming,
spreadsheets far outnumber computer languages, because they are more
powerful, and easier to use.  Of course the spreadsheet programming
systems have limits on what they can do, but we can learn from them.



Mon, 06 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

> 1) inability to detect undefined variables

The easist way to cope with this is IMHO to avoid undefined variables
alltogether. Eiffel, for example, initializes all variables with
useful values depending on their types. Most Oberon implementations
do this at least for pointers to support the garbage collection.

Modula-2 and Oberon were designed to allow higly efficient code
to be generated. The notion of undefined variables would require
additional memory (a BOOLEAN flag for every variable) and would
need time-consuming tests on each variable access to generate
exceptions. As long you don't have hardware supporting this, you
have to pay a huge price.

Please do not compare Modula-2 with languages that are usually
interpreted. It does not matter if your spreadsheet computes
something slowly but you would surely suffer if your operating
system (one of the domains of Modula-2) takes twice the time
as before.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/
PGP:    http://www.mathematik.uni-ulm.de/sai/borchert/pgp.html



Mon, 06 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:


> > 1) inability to detect undefined variables

> The easist way to cope with this is IMHO to avoid undefined variables
> alltogether. Eiffel, for example, initializes all variables with
> useful values depending on their types. Most Oberon implementations
> do this at least for pointers to support the garbage collection.

Arguably though at least for debugging you want to have variables generate an
immediate runtime exception on fetching an undefined value. It can be done at some
(usually serious) cost in speed, but it catches a whole class of bugs.
Initialising variables to a safe helpful value allows a subset of deterministic
incorrect behaviour to pass unchallenged. I prefer initialising memory and
variables to various hostile values - invalid if interpretted as a real or as a
pointer.

Quote:
> Modula-2 and Oberon were designed to allow higly efficient code
> to be generated. The notion of undefined variables would require
> additional memory (a BOOLEAN flag for every variable) and would
> need time-consuming tests on each variable access to generate
> exceptions. As long you don't have hardware supporting this, you
> have to pay a huge price.

But only in the debugging environment, and there were some static analysers about
that can make quite a lot of headway with fault finding access to undefined
variables etc in Modula code. I thought XDS did one, but I couldn't find their old
web page for it any more.

Quote:
> Please do not compare Modula-2 with languages that are usually
> interpreted. It does not matter if your spreadsheet computes
> something slowly but you would surely suffer if your operating
> system (one of the domains of Modula-2) takes twice the time as before.

Provided there is a decent native code compiler for production code it may not
matter.

I can't help thinking that having a Windows desktop that ran just 2x slower and
never hung up would be a major improvement. YMMV

Regards,
Martin Brown



Mon, 06 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)


Quote:
> 1) inability to detect undefined variables

Do you mean undefined or uninitialised? Other people have commented on
uninitialised (to do this relies on either reserving a value or
artificially increasing the size of the variable's storage space) but I'd
suggest that the ability to detect during execution whether a particular
module was linked in would be useful- this can obviously be done on top of
the MS DLL mechanism.

Quote:
> 2) lack of fail-soft arithmetic (like spreadsheets)

You're asking for exception handling.

Quote:
> 3) inability to directly model common peripherals, such as video
> screens, sound chips, 3D cards

What /exactly/ are you asking for here? Does it have any place in a
general-purpose language?

Quote:
> 4) lack of automatic order of computation (like spreadsheets)

I can accept this if you're talking about order of module initialisation,
but I don't think your comment makes sense unless you are implicitly
specifying preemptive threading.

One of the things on /my/ personal wishlist is the ability to force
multiple modules to conform to a template defining their exported
functionality, e.g. by something like:

DEFINITION MODULE FloppyDriver;

IMPORT DEFINITION StorageDriver;

END.

-- Mark Morgan Lloyd

--
-- [Opinions above are the author's, not those of his employers or
colleagues]



Mon, 06 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:



> > > 1) inability to detect undefined variables

> > The easist way to cope with this is IMHO to avoid undefined variables
> > alltogether. Eiffel, for example, initializes all variables with
> > useful values depending on their types. Most Oberon implementations
> > do this at least for pointers to support the garbage collection.

> Arguably though at least for debugging you want to have variables generate an
> immediate runtime exception on fetching an undefined value. It can be done at some
> (usually serious) cost in speed, but it catches a whole class of bugs.
> Initialising variables to a safe helpful value allows a subset of deterministic
> incorrect behaviour to pass unchallenged. I prefer initialising memory and
> variables to various hostile values - invalid if interpretted as a real or as a
> pointer.

REALs are easy as long as signalling NaNs are supported (thanks to
IEEE754 now on nearly all platforms). Pointers may be initialized to
NIL. So far so good. But what kind of hostile values do you suggest for
integers?

Quote:
> But only in the debugging environment, [...]

IMHO this is not very useful. To cite (using my errorneous mind) from
Hoare: What use are life belts in port (your test environment) if
you are dropping them before making way to the ocean -- the real life
environment? Usually preliminary tests are seldom performed in a
way that covers 100% of the code as many parts of it are simply not
reached under good weather conditions but in case of failures.

If all variables are initialized to well-defined values (NIL in
case of pointers, NaNs in case of REALs, 0 in case of INTEGERS etc),
you remove the remaining problems alltogether.

From my experience I simply do not believe in a separation of test and
production enviroments for software. My compilers, for example,
generate all runtime checks they are capable of on default and I never
switch them off. My Modula-2 compiler runs with all checks and 241
assertions and is still faster than any other Modula-2 compiler on the
same platform I have seen so far (it compiles itself in 7 seconds on a
400Mhz Sun despite its historical 4-pass design). Nearly all bugs of
that compiler were detected by crashes of the compiler (due to run time
checks, references of NIL, or failed assertions). Cases where wrong
code was generated silently were extremely rare so far. As some of
these failures were detected not by me, I was glad when the compiler
crashed and thereby put the blame on me.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/
PGP:    http://www.mathematik.uni-ulm.de/sai/borchert/pgp.html



Tue, 07 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

> REALs are easy as long as signalling NaNs are supported (thanks to
> IEEE754 now on nearly all platforms). Pointers may be initialized to
> NIL. So far so good. But what kind of hostile values do you suggest for
> integers?

For INTEGERs, MIN(INTEGER). This is a special case anyway because it
can't be negated (assuming 2's complement coding). CARDINALs are the
problem - I've often wanted to use the full range.

Martin



Tue, 07 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

> > REALs are easy as long as signalling NaNs are supported (thanks to
> > IEEE754 now on nearly all platforms). Pointers may be initialized to
> > NIL. So far so good. But what kind of hostile values do you suggest for
> > integers?

> For INTEGERs, MIN(INTEGER). This is a special case anyway because it
> can't be negated (assuming 2's complement coding).

But you consider MIN(INTEGER) still as a valid value for INTEGERs?

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/
PGP:    http://www.mathematik.uni-ulm.de/sai/borchert/pgp.html



Tue, 07 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

>From my experience I simply do not believe in a separation of test and
>production enviroments for software.

Hear, hear!

I distribute e-mail and ftp server software, and this used to include
exception handling that would ensure that the server kept running even
if there was a crash in one or more of the threads.  As a practical
matter, this meant that a crash triggered by one client would not
affect the other clients logged in at the same time.

Over time, I came to realise that this was the wrong thing to do.
It simply masked faults, making it likely that those faults would cause
obscure problems (e.g. running out of memory) at some much later
time.  I've now removed all the exception handlers.  If my program
crashes, I want it to crash RIGHT NOW where it's going to leave
meaningful evidence of what went wrong.  If there's some special
case (even if it's a rare case) that I'm not handling properly, I need
to know about it.

I have now moved towards the view that exception handling in
Modula-2 is useful only for quick-and-dirty software.  For production
work, exception handlers are an undesirable feature.

One of the nice things about the Wirth family of languages is that
the people who develop compilers for such languages have a tendency
to enable run-time checking as the default condition, i.e. you always
get it unless you explicitly turn it off.  In the C+ and D- family of
languages there's a tradition that run-time checks are always disabled
by default.

Example: software crackers have on several famed occasions found
a way to break security on certain network applications by arranging
to create data that runs off the end of an array.  This works only
because the software in question is written in C, which has no real
concept of "array".  Do the same thing to a Modula-2 program and
you'll almost certainly trigger a "subscript out of range" fault that
terminates the program before the damage is done.

--

http://eepjm.newcastle.edu.au



Wed, 08 Jan 2003 03:00:00 GMT  
 Top 10 Language Constructs (Modula2)

Quote:

> Over time, I came to realise that this was the wrong thing to do.
> It simply masked faults, making it likely that those faults would cause
> obscure problems (e.g. running out of memory) at some much later
> time.  I've now removed all the exception handlers.  If my program
> crashes, I want it to crash RIGHT NOW where it's going to leave
> meaningful evidence of what went wrong.  If there's some special
> case (even if it's a rare case) that I'm not handling properly, I need
> to know about it.
> I have now moved towards the view that exception handling in
> Modula-2 is useful only for quick-and-dirty software.  For production
> work, exception handlers are an undesirable feature.

But...But...But...

But exceptions are REQUIRED if you want to write programs that are
reliable.  So says the multitudes of experts on comp.lang.<mumble>

For what it's worth, I happen to agree with you.  Sort of.  While I
strongly disagree with the idea of disabling, removing, or otherwise
having separate compiler options for "debug" as opposed to "production"
releases, I've got to disagree that crashing right now is always the
best of ideas.  I reach this conclusing based upon recent experience
where I've spent quite a bit of time writing redundant servers for a
variety of services and run into the problem of having difficulty
telling when the system has failed over.

Yes, I want it to leave a trace I can feed into a post-mortem de{*filter*}
to find out what it was doing when it crashed and have a prayer of
figuring out how it got into that state.  Also, I've seen too many
systems go from repairable to completely unrecoverable to be too happy
with attempts at automatic error recovery.  However, I want it to scream
before it dies.  I also might want to do things like rewind the
transaction it's in the middle of when it crashes.  (Yes, I know that's
an attempt at an automatic error recovery.  I never claimed to be
particulary consistent.)  To be sure, it takes careful planning to do
this sort of thing with exceptions, but it is certainly possible to do
just that.



Wed, 08 Jan 2003 03:00:00 GMT  
 
 [ 27 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Top 10 Language Constructs (Smalltalk)

2. Top 10 Language Constructs (Forth)

3. Top 10 Language Constructs (Oberon)

4. Top 10 Language Constructs (Eiffel)

5. undefined variables (was Top 10 Language Constructs (Modula-2))

6. Top 10 Language Constructs (Scheme)

7. Top 10 Language Constructs (Ada)

8. Top 10 Language Constructs (Cobol)

9. Top 10 Language Constructs (Fortran)

10. Top 10 Language Constructs (Phyton)

11. Top 10 Language Constructs (Prolog)

12. Top 10 Language Constructs (Lisp)

 

 
Powered by phpBB® Forum Software