Ada requires too much typing!
in [ADA]
|
Prev: Lost in translation (with SPARK user rules)
Next: Sockets package in SPARK (Was: Lost in translation (with SPARK user rules))
From: John B. Matthews on 28 May 2010 11:52 In article <op.vdek5asaule2fv(a)garhos>, Yannick Duchêne (Hibou57) <yannick_duchene(a)yahoo.fr> wrote: > Le Fri, 28 May 2010 07:25:15 +0200, Luis Espinal <Luis_member(a)newsguy.com> > a écrit: [...] > > lack of operator overloading I prefer Ada's approach in this, but Java is acceptable. Here's a simple example implemented in both Ada and Java for comparison: <http://home.roadrunner.com/~jbmatthews/misc/groots.html> <http://sites.google.com/site/drjohnbmatthews/polyroots> > and checked exceptions were What is this about “checked” exceptions ? > (a non-Java guru talking). In Java, the presence of a suitable handler for checked exceptions is enforced at compile-time: <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2> The feature may be regarded as controversial: <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html> -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Dmitry A. Kazakov on 28 May 2010 13:31 On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote: > In Java, the presence of a suitable handler for checked exceptions is > enforced at compile-time: > > <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2> > > The feature may be regarded as controversial: > > <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html> BTW, this is the same issue as with Eiffel's "contracts" and Ada's assertions. The problem is misuse of exceptions: 1. IF the exception is a part of the contracts <=> the client is supposed to handle it, THEN it must be checked. 2. IF no client can handle it, THEN it shall not be, the program must rather abort itself or break into the debugger. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Georg Bauhaus on 28 May 2010 15:05 On 28.05.10 19:31, Dmitry A. Kazakov wrote: > On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote: > >> In Java, the presence of a suitable handler for checked exceptions is >> enforced at compile-time: >> >> <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2> >> >> The feature may be regarded as controversial: >> >> <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html> > > BTW, this is the same issue as with Eiffel's "contracts" and Ada's > assertions. The problem is misuse of exceptions: > > 1. IF the exception is a part of the contracts <=> the client is supposed > to handle it, THEN it must be checked. > > 2. IF no client can handle it, THEN it shall not be, the program must > rather abort itself or break into the debugger. 2. is what Eiffel programs do, but the compiler does not check the presence of exception handlers for postconditions that may fail (and thus raise an exception). If it did, will it not mean exception handlers pretty much everywhere?
From: Dmitry A. Kazakov on 28 May 2010 15:39 On Fri, 28 May 2010 21:05:00 +0200, Georg Bauhaus wrote: > On 28.05.10 19:31, Dmitry A. Kazakov wrote: >> On Fri, 28 May 2010 11:52:09 -0400, John B. Matthews wrote: >> >>> In Java, the presence of a suitable handler for checked exceptions is >>> enforced at compile-time: >>> >>> <http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2> >>> >>> The feature may be regarded as controversial: >>> >>> <http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html> >> >> BTW, this is the same issue as with Eiffel's "contracts" and Ada's >> assertions. The problem is misuse of exceptions: >> >> 1. IF the exception is a part of the contracts <=> the client is supposed >> to handle it, THEN it must be checked. >> >> 2. IF no client can handle it, THEN it shall not be, the program must >> rather abort itself or break into the debugger. > > 2. is what Eiffel programs do, but the compiler does not check > the presence of exception handlers for postconditions that > may fail (and thus raise an exception). If it did, will it not > mean exception handlers pretty much everywhere? No. Exceptions are supposed to propagate. A propagating exception is unhandled one. If you confuse 1 and 2 you get troubles. Another example from Ada is Program_Error, e.g. from Initialize/Finalize/Adjust. It is meaningless and very harmful. If you are in 2, it is too LATE to raise anything. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: BrianG on 29 May 2010 20:49
Jeffrey R. Carter wrote: > Peter C. Chapin wrote: >> >> However, the argument that I see some people putting forth on the >> Scala group >> is that conciseness is good because it saves typing. I really can't >> understand that. How hard is it to type? > > The important point is that in the real world, code is written once, but > read many times. I'm sure this is just as true with Scala as it is with > every other language. So saving typing at the cost of making it harder > to read is a false economy. Any project where money is involved should > take that into consideration. > > As Preben Randhol put it, "Saving keystrokes is the job of the text > editor, not the programming language." > Forget text editors, saving keystrokes is the job of the computer. And I've got just the computer for "Rex": a Sinclair ZX-81. Each key on the (chicklet) keyboard has a (BASIC) keyword. Rather than typing out G-O-T-O, you only type G and the computer fills in the rest. It's also context-sensitive, so you get the minimum typing to get the program you want (as long as you're not an experienced typer and type out the keywords anyway). Better yet - a computer I used in college had a hexadecimal keyboard, where you typed in machine code. Think of it: no verbosity, no "comments", no carriage returns; just raw hex. What could be more "efficient"? --Bg -- If writing programs were more important than reading them, we'd be programming with invisible ink. We wouldn't need a monitor. We wouldn't need to save the source code - compile it and you have the executable/object, what more do you need? |