Magic function

[Steven D'Aprano]

On Fri, 11 Jan 2008 17:36:10 -0800, Michael Tobis wrote:

> On Jan 11, 6:15 pm, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
>> Your users are *scientists*, and you don't trust their intellectual
>> ability to learn a programming language as simple as Python?
>>
>> Instead of spending time and effort writing, debugging  and maintaining
>> such a fragile approach, why not invest in a couple of introductory
>> books on Python programming and require your scientists to go through
>> the first few chapters? Or write out a one-page "cheat sheet" showing
>> them simple examples. Or, and probably most effectively, make sure all
>> your classes have doc strings with lots of examples, and teach them how
>> to use help().
>>
>> Some people problems are best dealt with by a technical solution, and
>> some are not.
>>
>> --
>> Steven
> 
> I am currently talking very similar trash on my blog, See
> http://initforthegold.blogspot.com/2008/01/staying-geeky.html and
> http://initforthegold.blogspot.com/2007/12/why-is-climate-modeling-
stuck.html
> 
> You seem to think that learning the simple language is equivalent to
> grasping the expressive power that the language provides.


I do? What did I say that led you to that conclusion?


> Yes, users are scientists. Therefore they do not have the time or
> interest to gain the depth of skill to identify the right abstractions
> to do their work.

I don't follow you. If they aren't learning the skills they need to do 
their work, what are they doing? Hammering screws in with a hacksaw? 
(Metaphorically speaking.)



> There are many abstractions that could be useful in science that are
> currently provided with awkward libraries or messy one-off codes.

I'm sure you're right. Attempts to make elegant libraries and re-usable 
code should be encouraged. The OP's attempt to dumb-down his library 
strikes me as a step in the wrong direction.


> The idea that a scientist should be expected to be able to write correct
> and useful Python is reasonable. I and the OP are relying on it.

Please go back and look at the example the OP gave. According to the 
example given, his users would find this too difficult to deal with:

obj1 = Obj(params1)
obj2 = Obj(params2)
...
bigobj = Bigobj(objects=[obj1,obj2])
bigobj.run()


That's not terribly complex code, thanks to Python's easy-to-use object 
model. Dropping the explicit construction of the Bigobj in favour of a 
mysterious, implicit auto-magic run() is a serious step in the wrong 
direction. Any scientist working with this can see exactly what is being 
run(), and not have to rely on hunting through the entire source code 
looking for Obj() calls he might have missed.

As simple as the above is, it could be made simpler. Judging from the 
example given, the Bigobj constructor doesn't need a keyword argument, it 
could just as easily take an arbitrary number of arguments:

bigobj = Bigobj(obj1, obj2, obj3, obj4...)


> The idea that a scientist should be expected to identify and build
> clever and elegant abstractions is not.

But that's their job. That's what scientists do: identify and build 
clever and elegant abstractions, such as Newton's Laws of Motion, Special 
Relativity, Evolution by Natural Selection, the Ideal Gas Laws, and so on.

Even climate change models are abstractions, and we would hope they are 
clever and elegant rather than stupid and ugly.



> If you think every scientist can
> be a really good programmer you underestimate at least one of what good
> scientists do or what good programmers do or what existing high
> performance scientific codes are called upon to do.

Read the OP's post again. His (her?) users aren't expected to create the 
toolkit, merely to use it. To create good toolkits you need both a master 
programmer and an expert in the field. It is an advantage if they are the 
same person. But to use such a good toolkit, you shouldn't need to be a 
master programmer.



-- 
Steven