It Hurts When I Do This
in [Fortran]
|
Prev: compile errors, please help.
Next: A digression
From: GaryScott on 18 Apr 2008 12:03 http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-this/ But we NEED a syntax that means "the entire array". Code should be self documenting. Of course, I typically just name arrays so that it's clear that it is an array (aArray, bArray, cArray), but it is fairly natural to want to specify a wildcard indicating whole array since it improves interpretability. It is available in other languages that I've used in the past.
From: Richard Maine on 18 Apr 2008 12:27 GaryScott <garylscott(a)sbcglobal.net> wrote: > http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-this/ I don't think I've seen that article before, but I think it is well done (as I'd expect from Steve). I also quite agree with its points. > But we NEED a syntax that means "the entire array". Code should be > self documenting. We do have a syntax that means the entire array - the array name. True, the syntax doesn't directly tell you that it is an array, but it does tell you that it is the entire of whatever the thing so named is declared to be. While I'm a big fan of writing clear and largely self-documenting code, I disagree that it helps to use a special notation to indicate that something is an array. Why pick on arrayness in particular? Down that path lies special notations for all attributes. Might as well go back to implicit typing, and disallow overriding the implicit type; then you can look at the variable name and know the type. Let's throw in conventions for all the other attributes as well. We need a syntax that tells you that something is the whole of a derived type. So as not to pick only on the "newfangled" f90 features, don't we need a syntax to tell you that something is all of a complex variable? Etc. Heck, let's throw out all declarations and encode everything in the syntax of referencing a variable. Seems to me like it is the same principle. I think it a mistake to throw all this kind of thing in the language. They aren't adding extra functionality - just notational convention. I don't see the point in picking on arrays in partucular. To the extent that one is just looking for a notational convention, we already have something suitable in the language. You've noted it; the variable name. Yes, it is up to the programmer has to select appropriate names. But then it would also be up to the programmer to use any such new language syntax... unless you incompatibly made it mandatory, invalidating all existing code that uses whole arrays. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: GaryScott on 18 Apr 2008 13:53 On Apr 18, 11:27 am, nos...(a)see.signature (Richard Maine) wrote: > GaryScott <garylsc...(a)sbcglobal.net> wrote: > >http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-t... > > I don't think I've seen that article before, but I think it is well done > (as I'd expect from Steve). I also quite agree with its points. > > > But we NEED a syntax that means "the entire array". Code should be > > self documenting. > > We do have a syntax that means the entire array - the array name. True, > the syntax doesn't directly tell you that it is an array, but it does > tell you that it is the entire of whatever the thing so named is > declared to be. > > While I'm a big fan of writing clear and largely self-documenting code, > I disagree that it helps to use a special notation to indicate that > something is an array. Why pick on arrayness in particular? Down that > path lies special notations for all attributes. Might as well go back to > implicit typing, and disallow overriding the implicit type; then you can > look at the variable name and know the type. > > Let's throw in conventions for all the other attributes as well. We need > a syntax that tells you that something is the whole of a derived type. > So as not to pick only on the "newfangled" f90 features, don't we need a > syntax to tell you that something is all of a complex variable? Etc. > Heck, let's throw out all declarations and encode everything in the > syntax of referencing a variable. Seems to me like it is the same > principle. > > I think it a mistake to throw all this kind of thing in the language. > They aren't adding extra functionality - just notational convention. I > don't see the point in picking on arrays in partucular. > > To the extent that one is just looking for a notational convention, we > already have something suitable in the language. You've noted it; the > variable name. Yes, it is up to the programmer has to select appropriate > names. But then it would also be up to the programmer to use any such > new language syntax... unless you incompatibly made it mandatory, > invalidating all existing code that uses whole arrays. It doesn't logically follow that to ask for a syntax for arrayness requires a syntax for any other attributes. The article makes it quite clear that it is a common thought process among programmers and a common pitfall. It definitely should have been done right the first time, but no, I wouldn't make it mandatory at this point. > > -- > Richard Maine | Good judgement comes from experience; > email: last name at domain . net | experience comes from bad judgement. > domain: summertriangle | -- Mark Twain
From: none on 18 Apr 2008 14:25 On Fri, 18 Apr 2008 09:03:06 -0700, GaryScott wrote: > http://softwareblogs.intel.com/2008/03/31/doctor-it-hurts-when-i-do-this/ > > But we NEED a syntax that means "the entire array". Code should be > self documenting. Of course, I typically just name arrays so that > it's clear that it is an array (aArray, bArray, cArray), but it is > fairly natural to want to specify a wildcard indicating whole array > since it improves interpretability. It is available in other > languages that I've used in the past. I read the article to mean that Steve *is* happy using <array name> to indicate the whole array. If modifying the code you would check its declaration, at some point; if just reading it, the atomic use of <array name> is sufficient. Steve wrote that there was an alternate 'wildcard', using (:), but that this usually hindered optimisation - and in the specific example in his article, prevented the user from getting the result wanted. Adding a new construct for such a specific operation - retrieving the whole array - when there are already two mechanisms for doing this - , on the grounds that this would 'clarify' the array retrieval, seems an uncessary burden.
From: Clive Page on 18 Apr 2008 14:32
In message <9bfddca3-b45a-4649-ab77-1f894baecb8d(a)b64g2000hsa.googlegroups.com>, GaryScott <garylscott(a)sbcglobal.net> writes >It doesn't logically follow that to ask for a syntax for arrayness >requires a syntax for any other attributes. The article makes it >quite clear that it is a common thought process among programmers and >a common pitfall. I for one don't agree. It may be a common pitfall among programmers used to inferior languages such as C, C++, and Java which really don't support much beyond simple scalar operations, but surely Fortran programmers are used to being able to use the name of an array and have it mean the entire array. This has been standard practice in many statements (READ, WRITE, PRINT, CALL, DATA, SUBROUTINE, FUNCTION, etc) since Fortran-II (I think), certainly since Fortran-IV/Fortran 66. The main change since then is that the whole-array notation was extended to every other appropriate context, and especially to expressions and assignments. Of course this change came in as recently as 1990. I really don't think that a new notation is required just because some programmers are a bit slow to catch on to the new thought processes required. Of course it doesn't help that so many other languages are still stuck in the scalar era. Perhaps it's these that need a change of syntax? If they supported whole-array operations, as a modern language surely should, the problem wouldn't arise. :-) -- Clive Page |