N best things about Ada?
in [ADA]
|
From: Robert A Duff on 12 Jul 2010 11:13 Shark8 <onewingedshark(a)gmail.com> writes: > People have mentioned packages, non-textual-substitution generics, and > such. > But one thing that could come in handy is the named parameters, and it > is something I like; one of those "little things." Yes. It's such a small feature, yet has a huge benefit. People should use it more often. Another small feature: underscores in numeric literals. One of my pet peeves is when I have to carefully count the zeroes in 10000000, when it's so easy to write 10_000_000. > "Circle( Radius => 23, X => 28, Y => 14 );" will always be more > readable than "Circle( 23, 28, 14 );" plus, there's the added benefit > that 1) changes in parameter-ordering will not impact calls of this > sort, & 2) the users of the functions/procedures can place the more > pertinent parameters [to their task] more prominently [e.g. first]. Do you have any examples of that last part? That is, examples where using different parameter orders in different calls makes the code more readable? I think that sort of inconsistency usually makes the code less readable. I wouldn't mind a rule that says the parameter order has to match the declaration. (A Legality Rule, not a Name Resolution Rule!) - Bob
From: Shark8 on 12 Jul 2010 12:14 On Jul 12, 9:13 am, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > Shark8 <onewingedsh...(a)gmail.com> writes: > > People have mentioned packages, non-textual-substitution generics, and > > such. > > But one thing that could come in handy is the named parameters, and it > > is something I like; one of those "little things." > > Yes. It's such a small feature, yet has a huge benefit. > People should use it more often. > > Another small feature: underscores in numeric literals. > One of my pet peeves is when I have to carefully > count the zeroes in 10000000, when it's so easy > to write 10_000_000. > > > "Circle( Radius => 23, X => 28, Y => 14 );" will always be more > > readable than "Circle( 23, 28, 14 );" plus, there's the added benefit > > that 1) changes in parameter-ordering will not impact calls of this > > sort, & 2) the users of the functions/procedures can place the more > > pertinent parameters [to their task] more prominently [e.g. first]. > > Do you have any examples of that last part? That is, examples > where using different parameter orders in different calls > makes the code more readable? > > I think that sort of inconsistency usually makes the code less readable. > I wouldn't mind a rule that says the parameter order has to match > the declaration. (A Legality Rule, not a Name Resolution Rule!) > > - Bob Well, in image-manipulation there are a number of formats that store their information Y, then X. (That is they use column-major order instead of row-major order.) Given a call: "Get_Pixel(K,J);" Is that in familiar X-Y space, or in the image's native Y-X space? Get_Pixel( X=> K, Y=> J); and Get_Pixel( Y=> J, X=> K); are unambiguous, and given the situation/problem you may be thinking in one or the other. Let's say you were to want to extend/overload Get_Pixel for a Point- type: Type Point_Type is record Y, X : Integer; end record; You could write it as: Function Get_Pixel( Point : Point_Type ) return Pixel_Value is begin Return Get_Pixel( X=> Point.X, Y=> Point.Y); end;
From: Simon Wright on 12 Jul 2010 15:44 Robert A Duff <bobduff(a)shell01.TheWorld.com> writes: > I wouldn't mind a rule that says the parameter order has to match the > declaration. (A Legality Rule, not a Name Resolution Rule!) Sounds more like a style rule (or an AdaControl rule) to me. Like the GNAT style rule that wants subprograms to be in alphabetical order.
From: Nasser M. Abbasi on 12 Jul 2010 17:06 On 7/12/2010 7:05 AM, Shark8 wrote: > People have mentioned packages, non-textual-substitution generics, and > such. > But one thing that could come in handy is the named parameters, and it > is something I like; one of those "little things." > > "Circle( Radius => 23, X => 28, Y => 14 );" will always be more > readable than "Circle( 23, 28, 14 );" plus, there's the added benefit > that 1) changes in parameter-ordering will not impact calls of this > sort,& 2) the users of the functions/procedures can place the more > pertinent parameters [to their task] more prominently [e.g. first]. Yes. One way to simulate the above when using languages that do not have named parameters but do have records or struct, is by passing a record, and stick the parameters in the record as fields. The caller will read the parameters out by the _name_ of the record field. So, one can change a position of a field in the record, and the called function do not have to change, since it is reading the data by the field name. It is not as good as named parameters, but one way around it. This worked in Matlab, which is interpreted. One nice side benefit is that if one has large number of parameters in the call, they now all collapse to just one parameter (the record) which holds everything. One might have to compile everything in other stronger typed static languages? but the called function code should not have to change. --Nasser
From: Warren on 13 Jul 2010 12:18
expounded in news:97691fd2-7411-4ccc-bc7b-290aca633cd5 @z30g2000prg.googlegroups.com: > Serious question: What do you consider the N best things / strong > points / biggest benefits of using Ada? I'm asking as part of my case- > building for using Ada at work. Of course I have my own list, but I > don't have anywhere near the Ada experience of most of you folks. > > Thanks. In addition to all of the other posts: - Variant records (vs C unions) Having proper "checked" variant records has saved my bacon many times in a large project. There is nothing better than early bug detection! Warren |