Arthur- As a simplification, admittedly a cartoon, most professional mathematicians often care very deeply about a very few things for a long time (where a mathematician might spend ten years thinking about, say, proving Fermat's last conjecture) where they refine a concise notation they understand in a specific problem domain (with some cultural norms perhaps like dX), while most professional programmers need to care somewhat about a lot of things which change from function to function and application to application (where in a year a programmer might work on thousands of functionsand tens of applications, and perhaps read the intent of hundreds of thousands of function calls). That is why, for example, when I read code written by mathematicians they feel it totally acceptable to use, say, "rd" everywhere in a small program, when I as a professional programmer would prefer "rainfallPerDay_mm", because to me I experience their program as just one little day trip on a lifelong journey, and life is too short to spend hours puzzling over cryptic variable names or mathematical items in simulations used without units (and often inconsistently in hard to find bugs where the code works but is wrong).
I think this issue of argument labeling may fall into the same category of variable naming. Sure, if you maintain one program only and it is short, or if you spend a lot of time in one problem domain, then not labeling arguments so anyone can read them may be acceptable. But if you have to read and understand the intent of literally tens of thousands of function calls per year across dozens of libraries, then writing or reading something like "calc(rd, i)" or in your example "Line(point1,point2)" just does not cut it IMHO. (The Python codebase itself may suffer from something of the same effect in parts.) What about constructors like "Line origin: 10 @ 10 angle: 35 degrees distance: 10 mm" (which is easy to have in Smalltalk syntax) and so on? And I bet you can read what it means not even knowing Smalltalk. Would you rather read: "Line(10, 10, 35, 10)"? Or at best: "Line(Point(10, 10), 35, 10)"? Which is clearer? I think this goes beyond my bias as being experienced using Smalltalk system keyword syntax. Not to be too hard on you or Kirby, but I think it is easy to not see the value of the unfamiliar, and there is a lot functional foo() syntax makes difficult and awkward looking (Lisp, a Python ancestor in a sense, has a bit of this problem too). Again, just because Smalltalk has this and Python does not does not mean I'm saying "use Smalltalk". I'm just saying, how can Python get this feature? Maybe it can't. Then my next thing is, can the two syntaxes live side by side -- a possible area for exploration. --Paul Fernhout Arthur wrote: > Paul D. Fernhout wrote: > > >>In the syntax case, I am continuing to point out that Smalltalk's keyword >>syntax (e.g. "Point x: 10 y: 20" versus "Point(10, 20)" ) produces code >>where all arguments are labeled and so it is easier to read and >>understand. >> > > That is, IMO, an arbitrary point of view, at best. > > Touches a particular nerve with me because I went to great trouble in > the design of PyGeo to *avoid* the use of keyword arguments, feeling it > in fact important that in creating a construction one should be in > geometry mindset mode, not programmming mindset mode, and therefore > *not* have to be explicit in stating the obvious. > > See > http://pygeo.sourceforge.net/docs/Overview.html#built-in-geometric-intelligence > > The point is not whether my design is right or wrong, but that I found > myself to be using a tool that allowed me to express my design exactly > as I wanted to - right or wrong. > > Would I have had the same right to be wrong using Smalltalk? > > Art > > _______________________________________________ > Edu-sig mailing list > [email protected] > http://mail.python.org/mailman/listinfo/edu-sig > > _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
