Mailman 3 September 2005 - Edu-sig

Re: [Edu-sig] quantum instance
by Laura Creighton 19 Sep '05

19 Sep '05

In a message of Sun, 18 Sep 2005 16:45:21 PDT, "Kirby Urner" writes: >Perhaps my version of Python is evolving at a faster rate, and in differe >nt >directions, than you necessarily need in your version, for what you're >trying to do. What's the harm in that, as long as your code still runs? > >Kirby There is enormous potential harm in this. The problem is that programming is not an individual activity. When new features make code harder to read, or harder to understand, then readers are penalised at the expense of writers. When bugs are easier to make, or harder to detect when reading code, then everybody suffers. This is terrible for the productivity of a company. Once your company is beyond a certain size -- the exact number is subject to debate, and it varies depending on what language you use -- and once your codebase is beyond a certain size, you will find that you spend far, far, far more time _reading_ code than _writing_ it. The more senior you are, the worse this is, and managers often end up writing little or no code at all. This means that any productivity gains you get when you add {feature} which makes it easier to write code X has to be weighed against the productivity losses when you have to read {feature}. Since readers outnumber writers, there comes a point where no feature should be added that produces less-readable code, on the grounds of productivity gains to the code-writers alone. Remember, the productivity of a company is not driven by the speed at which your coders can write new code. Instead it is the speed at which they can understand the codebase, and the ease in which they can make modifications to it, and how bug-free those modifications are that matter. So if your new feature makes the code harder to read, it had better make certain bugs harder to make, or certain modifications easier to make in a bug free way, or have some other benefit. Some languages have developed the way they have precisely because they have persued some other benefit to the exclusion of all else. C++ sacrifices readability for speed. This was a fine trade for those people who absolutely must have the speed. But as CPUs got faster, people found their companies were more productive using something else. If you have worked commercially, then you will already be familiar with this situation. 'I don't have time to understand this code, I will just rewrite it instead'. This happens all the time. Writing is easy. Understanding is hard. But every time this happens, there is an indication that something is seriously wrong in your company. The fact that it is wrong in everybody else's company too is no excuse, just a sad commentary on the state of the art. Was the original code too poorly written? poorly documented? Is the new programmer too lazy to read the code? Too unskilled at reading code? Is the old code obscure but really damn excellent at something important, and the new version inferior? Will it cause subtle bugs? What about the reabability of the new version? Next week will somebody come along, not understand _it_ either, and reinvent the wheel a third time? Sometimes the problem is with the language itself. Take Perl. I never bother, any more, trying to deeply understand what any Perl script I find is doing. I just rewrite it in Python. I will never have any confidence in my ability to 'understand' what an arbitrary Perl script does. I've been wrong too often. One of the sad things about life as a commercial programmer is that often only the most junior programmers get to write code all day. This is because somebody else has come and given them the specs and told them what to write. Everybody else has to figure out what to write and where to write it, which requires being familiar with the code base, which requires reading it regularly, which takes time. This means that the coolest in new features, those meant to be used _sparingly_ fall directly into the hands of those who do not have the maturity and experience to know when not to use them. With predictable results. :-) This means come code review time, you have to waste a whole bunch of time explaining to your junior people why they need to rewrite their code to not use this feature. This makes code review a lot more painful and acrimonious than it was. And it is difficult on the reviewer. What do you say when you are only 65% convinced that this is a poor use of {feature}? Especially when what you want to say amounts to 'my XX years of experience in the field say that this is too cutesy?' Your junior programmers may only conclude from this that you are an senile old fart. You may conclude that they lack the wisdom that God gave green apples. Age-based splits in your company are among the hardest things to combat and sap morale and team building. Pair programming will not work unless there is mutual respect. In general, the greater the difference between 'your best people' and 'your worst people' the harder productivity suffers. If the language is hard to use, you may find out that only your top people provide positive value to the company. Your worst people subtract value. Not only do the things they write have to be rewritten, but everybody wastes time on bugs they caused, and talking to them with their problems and so on and so forth. I once managed a project that was late, and the only way we found to fix it was to take the 6 worst people on the team and send them to the other side of the country to take 3 weeks of training in some damn thing that wasn't even relevant to what our company did -- I forget what. Then everybody else got the job done. But those 6 people didn't learn much about how to be productive. What they really needed was training in UI design and how to use C++ without screwing up so much. But Andrew Koenig hadn't written _C++ Traps and Pitfalls_ yet, http://www.accu.org/bookreviews/public/reviews/c/c002114.htm so we couldn't give them a course based on it. And so it goes. Some languages have grown so much that only experts can be productive with it. What's more, even after you have your own company in shape, with nobody abusing the new features any more, you still have to interface with code written by people who do not work for your company. And they may not have as strict a set of standards as you do. If the innappropriate use of a new feature makes for buggy code, then you may be forced to not use some package that over-uses the feature despite its attractiveness in other ways. And you have absolutely no control over these people. Even deciding whether to use somebody else's code requires reading it. If the code is hard to read, you may find that you do not have the time. Obscure language features can make 'spot the poorly written code' game a lot harder. What you need is a way to quickly tell if the code you are reading is good or not. For my own peace of mind, I have decided that 'anybody who over-uses language feature X as much as those guys do is statistically unlikely to be up to anything good' - but I know as well as anybody that 'statistically unlikely' is not the same thing as 'never'. What opportunities are being missed? It is the tragedy of the commons all over again. Code-writers have the interest and motivation to add every feature they dream up into the languages they create, in the same way that sheep-owners have the interest and motivation to overgraze the commons. Laura

3 2

Re: [Edu-sig] quantum instance
by Arthur 19 Sep '05

19 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > > I'm glad I'm not confined to using your version of Python. My other problem is this: Did somebody forgot to mention to me, pre-Python2.2, that the language was missing a fundamental construct for the proper configuration of the proper API framework? And allowed me go about my business of constructing improper API frameworks - because that is what the language supported. Is it the same somebodies who jump at me when I question the new Python who would have jumped at me if I had questioned the old? It often seems so. Is information hiding also part of community building? If so, what is being hidden now? Art I don't believe the above, BTW - as long as I stick to my guns that properties are a minor piece of syntax sugar with a lot being read into their appearance in the lnaguage. And that if Guido was all-seeing he might have anticipated a lot more than intended being read into them. Or else I don't want to believe the above - so I stick to my guns. Art

3 2

Re: [Edu-sig] quantum instance
by ajsiegel＠optonline.net 19 Sep '05

19 Sep '05

----- Original Message ----- From: Kirby Urner <urnerk(a)qwest.net> Subject: RE: [Edu-sig] quantum instance > How a particular programming language needs to work to satisfy a > use case > needn't trump the basic intuitions of the user. You want to have your intuition as to someone else's intuition control - in a scientific setting. We are at unscience**2 - before we get started. The closest thing to reality we might have to grasp unto is the grammar of the language in which we are choosing to converse. I would urge you to go with that. I will, in any case. In part at the urging of *my* version of Python. 2.4 Art

2 1

Re: [Edu-sig] quantum instance
by ajsiegel＠optonline.net 19 Sep '05

19 Sep '05

----- Original Message ----- From: Kirby Urner <urnerk(a)qwest.net> Date: Monday, September 19, 2005 12:18 pm Subject: RE: [Edu-sig] quantum instance > I want to be able to express user intuitions about what's a method and > what's an attribute drawing from a knowledge domain. I don't want to > instruct a user in how Python must necessarily force a different view. Working with, rather than against, others' misaligned intuitions is the anti-thesis of the scientific spirit. You don't propose that there is no meaningful distinction between methods and attributes. You might be able to con me into believeing *that*, at least. ;) Instead you acknowledge the distinction but are consciously using the power to shuffle appearances to appease and re-enforce intuitions that happen to be wrong. I have to suppose that a intepretation of computer science that seems to support that approach is a misreading of the science. I am a great believer in the proposition that in the end, Reality wins. Put properties away in your use case, and you have no choice but to transcend the users' misaligned intuitions, and align with reality. I don't for a moment believe that can be harmful to your scientists/users. All of which is besides the point. Please stop implying that you have some insight that Python is encouraging you toward this approach. It's slander - as far as I am concerned. Art

2 1

Re: [Edu-sig] quantum instance
by Arthur 19 Sep '05

19 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > Sent: Sunday, September 18, 2005 7:45 PM > To: 'Arthur'; edu-sig(a)python.org > Subject: RE: [Edu-sig] quantum instance > > > > Apparently many programmers felt this lack, including Guido, and added > > > the missing capability. > > > > Can you please support your statement! > > > > The fact that it was added isn't evidence programmers wanted it added? Though not necessarily for the purposes you seem to suppose. > > > Guido added properties to the language. No doubt. He says they are about > > "managed attributes". His example in the original presentation of the > use > > of properties was quite narrow. In fact it was only in referring back to > > it that I feel I began to get my head on straight about what properties > > were really intended to be about (IMO). > > > > I believe I am interpreting his purpose much more carefully then are > you. > > > > You feel otherwise. > > The whole idea of attributes managed through setters and getters > (mutators) > is a known design pattern. SmallTalk wouldn't even allow direct > assignment > to attributes, right? *All* access to variables is "managed." > Setters and getters are built into C# as well, at the syntax level. Not > because of Python though. We're talking about a feature of the OO model > that's been around for awhile. Python acquired this feature later in its > development, but not out of the blue. Python is not Java or C# or Smalltalk. I know - because if it were I wouldn't be programming in it. > What's wrong with "group think"? I know we're supposed to reflexively > dislike the sound of that, but when a community reaches a consensus, based > on professional history and prior experience, must it always be wrong? > > I feel the explanations put forward for why the property feature was added > have made plenty of sense. I have heard 3 or 4 explanations. And don't see much logical connection between them. It sometimes appears that community ethos is to work backward form the fact that it is there, to the knowing explanation for why its good its there. My only objection to it being there - in fact - is the lack of consensus as to the compelling reason it is necessary. There seems to be agreement, in fact, on only this one aspect of the reason for its presence as a built_in function. The fact that the reason is compelling. Whatever the hell it is. Art

3 4

Re: [Edu-sig] quantum instance
by Laura Creighton 19 Sep '05

19 Sep '05

In a message of Mon, 19 Sep 2005 12:21:28 +0200, Laura Creighton wrote: <probably too much> I just want to mention that I like properties. I think they make the code easier to read. I've read too much code where people who wanted the behaviour of properties got out __getattr__ and did it wrong. Or decided that some hideous thing using metaclasses was the way to go. Or that using __slots__ to restrict access was a fine idea. So I think that code readability has improved. My problem with properties is some of the people who use them. There is a class of people who go around compulsively adding restrictions, wherever they go, whenver they cannot think of a reason not to. It makes them feel 'safer' or 'more professional' or something. Unfortunately, this desire to over-control everything frequently shows up in people who have no more imagination than a turnip. This is a bad combination. Laura

1 0

Re: [Edu-sig] quantum instance
by Arthur 18 Sep '05

18 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > Sent: Sunday, September 18, 2005 4:44 PM > To: 'Arthur'; edu-sig(a)python.org > Subject: RE: [Edu-sig] quantum instance > > > My other problem is this: > > > > Did somebody forgot to mention to me, pre-Python2.2, that the language > was > > missing a fundamental construct for the proper configuration of the > proper > > API framework? > > Apparently many programmers felt this lack, including Guido, and added the > missing capability. Can you please support your statement! Guido added properties to the language. No doubt. He says they are about "managed attributes". His example in the original presentation of the use of properties was quite narrow. In fact it was only in referring back to it that I feel I began to get my head on straight about what properties were really intended to be about (IMO). I believe I am interpreting his purpose much more carefully then are you. You feel otherwise. We are in Lit class arguing interpretation, the author's intent. Some authors successfully use ambiguity to their advantage. Perhaps there is a good deal here. But in this milieu I can't believe a straight forward reading of the author's stated intent - which is where I feel I am - is without merit. Maybe the cigar is just a cigar. > To answer your question: yes, no one thought to tell you -- not clear > what > that'd have accomplished. It's your responsibility to read the PEPs. > > > And allowed me go about my business of constructing improper API > > frameworks - because that is what the language supported. > > > > Is it the same somebodies who jump at me when I question the new Python > > who would have jumped at me if I had questioned the old? It often seems > > so. > > You're free to raise objections at any point along the way, no? Others > do, > and often in tones less dark and paranoid, which is probably why they > sometimes get more attention. I am dark and paranoid when I confront what I (rightly or wrongly) interpret as some form of group think. There are reasons for it. Apologies. Art

2 1

Re: [Edu-sig] quantum instance
by Arthur 18 Sep '05

18 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > Sent: Sunday, September 18, 2005 11:41 AM > To: 'Arthur'; edu-sig(a)python.org > > I'm glad I'm not confined to using your version of Python. As I said, so am my. I have my confidence scale. But as I've said previously -it's *never* 10 out of 10. But I do I think we have no choice but to teach in a way that let's our students know there are competing versions in play. I think *that* with a very high level of confidence. Art

2 1

Re: [Edu-sig] quantum instance
by Arthur 18 Sep '05

18 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > Sent: Saturday, September 17, 2005 9:07 PM > To: 'Arthur'; edu-sig(a)python.org > Subject: RE: [Edu-sig] quantum instance > > > > Your Python version - from what I can see - works different. > > > > Art > > OK, fun. My Python version goes more like this: > > Consider if client Z, inhabitant of knowledge domain X, would tend to > think > of this object-related foo as a noun or a verb My clients use a version of Python compatible to my own. But have no interest in what I might tend to think they might tend to think. They like information - hard information. Art

2 1

Re: [Edu-sig] quantum instance
by Arthur 18 Sep '05

18 Sep '05

> -----Original Message----- > From: Kirby Urner [mailto:urnerk@qwest.net] > Sent: Saturday, September 17, 2005 7:41 PM > To: 'Arthur'; edu-sig(a)python.org > Subject: RE: [Edu-sig] quantum instance > > > Let's not continue until we figure out why this isn't working for you. My version works something like this (though this is admittedly a slightly simplified version): >>If type(attribute)=='set by assignment' _ and (needs(setting) or needs (getting)) =='something unusual': see if property function might help else: forget property function exists Your Python version - from what I can see - works different. Art

2 2