From: Georg Bauhaus on
On 13.07.10 18:18, Warren wrote:

> There is nothing better than early bug detection!

Indeed! Finding type errors in trace output after
run-time is another way of type checking. I don't find it so
productive. But it is both popular and respectable,
since, for example, Python applications on Google App Engine
work that way. And it does work.

Most of the time.

If you develop the skills to guess correctly ...

So your argument doesn't carry enough weight: Google is big,
GAE is inexpensive at first, Python is reasonably popular.
This all shows there *is* something better than
early bug detection!

Don't bother with early type checking performed by
language translators. Learn how to write correct code, instead!

Use test cases! O.K., they work a little different
in the testing environment...

Phew. Sorry. I guess you see what I'm currently doing.
I should take notes of the minutes spent in finding stupid
mistakes like mixing str/unicode + encoding vs binary strings
vs strings of limited size, the latter being a restriction
that is enforced after deployment only. Yes, most of this can
be explained. But it could be enforced by a compiler, using
type checking ...

How much does type checking save?
Can this be spelled out in time and money?
From: Warren on
Georg Bauhaus expounded in news:4c3ca07c$0$6889$9b4e6d93
@newsspool2.arcor-online.net:

> On 13.07.10 18:18, Warren wrote:
>
>> There is nothing better than early bug detection!
>
> Indeed! Finding type errors in trace output after
> run-time is another way of type checking. I don't find it so
> productive. But it is both popular and respectable,
> since, for example, Python applications on Google App Engine
> work that way. And it does work.
>
> Most of the time.
>
> If you develop the skills to guess correctly ...
>
> So your argument doesn't carry enough weight: Google is big,
> GAE is inexpensive at first, Python is reasonably popular.
> This all shows there *is* something better than
> early bug detection!

I think you just bent the meter needle of my sarcasm
detector, heh heh.

Warren
From: Jeffrey R. Carter on
On 07/13/2010 09:18 AM, Warren wrote:
>
> There is nothing better than early bug detection!

To which we can add completeness checks for case statements and record aggregates.

In fact, aggregates in general. I take them for granted now, but I can remember
using languages that didn't have them.

I remember watching the videos of the "Ada Launch" (Ada 80, 1980 Dec 10) and
Barnes presenting a generic discrete (bit-mapped) set package. That was quite a
revelation for me. I had read about, but not really understood, information
hiding; seeing packages was the light-bulb event for me. When I saw the use of
an array aggregate as a "literal" actual parameter for the make-set function I
realized that this language was more expressive than anything I'd used.

--
Jeff Carter
"When Roman engineers built a bridge, they had to stand under it
while the first legion marched across. If programmers today
worked under similar ground rules, they might well find
themselves getting much more interested in Ada!"
Robert Dewar
62
From: Pascal Obry on

My list would be:

1. Packages as organizational units not mixed-up with object support

2. Separation of specification from implementation (body)

3. Unconstrained objects, can even be declared on the stack
(no much need for dynamic allocation).

4. Representation clauses for precise data representation (e.g., for
hardware interfacing)

5. Support for concurrent and distributed applications.

6. Great readability (e.g., begin/end instead of curly braces)

7. Sound generic support

8. A good (well thought out and reviewed) language standard

9. The GNAT compiler's great error and warning messages.

10. The availability of SPARK when very high (safe & secure) assurance
is needed.

--

--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

From: Nasser M. Abbasi on
On 7/13/2010 12:05 PM, Pascal Obry wrote:

>
> 6. Great readability (e.g., begin/end instead of curly braces)
>

fyi, the new kid on the block (F#) has done away all together of the
curly braces and begin. Like Python as well.

These languages use space indentation as part of the logic of the
program. The idea is that less "clutter" improves readability.

From MS web site om F#

"The lightweight syntax is shorter and uses indentation to signal the
beginning and end of constructs, rather than additional keywords like
begin, end, in, and so on"

From Python web site:

"Python functions have no explicit begin or end, and no curly braces to
mark where the function code starts and stops."

I am still not sure which is better. Using an explicit BEGIN END or
space indentation.

--Nasser