[Edu-sig] Smalltalk syntax benefits

[Paul D. Fernhout]

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
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
> 
>