From: Georg Bauhaus on 13 Jul 2010 13:21 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 13 Jul 2010 13:34 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 13 Jul 2010 13:51 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 13 Jul 2010 15:05 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 13 Jul 2010 15:26
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 |