The Industry choice

[Cameron Laird]

Re: The Industry choice

In article <41d7def6$0$742 73$ed2619ec@ptn-nntp-reader03.plus.n et>,
Mark Carter <mcturra2000@ya hoo.co.uk> wrote:

[Roy Smith]

Re: The Industry choice

claird@lairds.u s (Cameron Laird) wrote:
[color=blue]
> Let me add a cautionary note, though: Big Companies,
> including Oracle, Software AG, IBM, Cisco, and so on, have
> adopted Tcl over and over. All of them still rely on Tcl
> for crucial products. All of them also have employees who
> sincerely wonder, "Tcl? Isn't that dead?"[/color]

A lot of people laugh at Tcl, but it's really a very useful tool. In my
last job, we did a major component of our product (SNMP-based network
management package) in Tcl, probably on the order of 10 kloc. It has
its limitations, but it's very easy to learn, very easy to embed and
extend, and reasonably fast. It certainly blows away shell scripting.

Around here, AOL/Moviephone has been trolling for years for Tcl people;
I guess that counts as a big company.

[beliavsky@aol.com]

Re: The Industry choice

Roy Smith wrote:[color=blue]
>I think you've hit the nail on the head. In awk (and perl, and most
>shells, and IIRC, FORTRAN), using an undefined variable silently gets
>you a default value (empty string or zero). This tends to propagate
>errors and make them very difficult to track down.[/color]

You may recall correctly, but Fortran compilers have improved. The
following Fortran 90 program

integer, parameter :: n = 1
real :: x,y=2.0,z(n)
print*,"dog"
print*,x
z(n+1) = 1.0
print*,z
end

has 3 errors, all detected at compile time by the Lahey/Fujitsu Fortran
95 compiler, with the proper options:

2004-I: "xundef.f", line 2: 'y' is set but never used.
2005-W: "xundef.f", line 4: 'x' is used but never set.
2153-W: "xundef.f", line 5, column 1: Subscript out of range.

At run time, the output is

dog
The variable (x) has an undefined value.
Error occurs at or near line 4 of _MAIN__

Running Python 2.4 on the Python analog,

n = 1
y = 2.0
z = range(n)
print "dog"
print x
z[n] = 1.0
print z

one error is caught:

dog
Traceback (most recent call last):
File "xundef.py" , line 5, in ?
print x
NameError: name 'x' is not defined

You will see the out-of-bounds error for z only after fixing the
undefined-x error. No warning is ever given about y, which is set but
never used. In practice, 'print "dog"' could be some operation taking
hours. Can PyChecker find all the problems in a single run, without
executing 'print "dog"'? If so, it would be great if it were integrated
with the CPython interpreter.

One reason interpreted languages like Python are recommended to
beginners is to avoid the edit/compile/debug cycle. But I think it is
faster and less frustrating to have many errors caught in one shot.

[Roy Smith]

Re: The Industry choice

In article <cr99pd$rff$1@p anix3.panix.com >, aahz@pythoncraf t.com (Aahz)
wrote:
[color=blue]
> In article <xuTBd.66280$Jk 5.42292@lakerea d01>,
> Steve Holden <steve@holdenwe b.com> wrote:[color=green]
> >Aahz wrote:[color=darkred]
> >> In article <7xacrs230c.fsf @ruckus.brouhah a.com>,
> >> Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote:
> >>>
> >>>I was pretty skeptical of Java's checked exceptions when I first used
> >>>them but have been coming around about them. There's just been too
> >>>many times when I wrote something in Python that crashed because some
> >>>lower-level function raised an exception that the upper level hadn't
> >>>been expecting, after the program had been in use for a while. I'd
> >>>sure rather find out about that at compile time.
> >>
> >> That's funny -- Bruce Eckel talks about how he used to love checked
> >> exceptions but has come to regard them as the horror that they are.
> >> I've learned to just write "throws Exception" at the declaration of
> >> every method.[/color]
> >
> >Pretty sloppy, though, no? And surely the important thing is to have a
> >broad handler, not a broad specification of raisable exceptions?[/color]
>
> Yes, it's sloppy, but I Don't Care. I'm trying to write usable code
> while learning a damnably under-documented Java library -- and I'm *not*
> a Java programmer in the first place, so I'm also fighting with the Java
> environment. Eventually I'll add in some better code.[/color]

The whole point of exceptions is that they get propagated automatically.
If I'm not going to catch it, why do I have to even know it exists? I
don't consider "throws Exception" to be sloppy, I consider it to be
programmers voting with their feet.

[Mark Carter]

Re: The Industry choice

Cameron Laird wrote:[color=blue]
> In article <41d7def6$0$742 73$ed2619ec@ptn-nntp-reader03.plus.n et>,
> Mark Carter <mcturra2000@ya hoo.co.uk> wrote:
> .
> [tale of *very*
> typical experience
> with non-software
> engineers]
> .
> .
>[/color]


Don't start me! Dammit, too late ...

I've noticed that they have an overwhelming obsession with GUIs, too.
They design wizards for everything. Damn pretty they are, too. Albeit a
bit flakey. They seem to conflate pretty interfaces with good interfaces
and good software.

I used to joke that since our software wasn't particularly magical, it
didn't need wizards. But I think I just ended up sounding bitter.

We once had a bit of software that we thought we'd like to turn into a
generic application. The focus on improvements was, predictably enough,
that we should design a GUI that could do anything a client would likely
to want to do. It was my opinion, though, having seen the very
"special-cases" nature required in the original software, that it was
almost impossible to predict exactly how a customer might want the
product tailored. I suggested that what they really needed was a library
(Python would have been good for this, Lisp might have been even better)
that could be extended as required. GUIs second, functionality first.
But hey, what would I know. Fortunately, the whole thing's been put on
the back burner.

And trying to get through to them why source control makes sense, that
when more than one person works on a project, some form of coordination
is required, that copying and pasting code is evil, and that Excel
probably isn't the hammer for every nail.

Honestly, I thought (real) engineers were supposed to be clever.

[Donn Cave]

Re: The Industry choice

Quoth Paul Rubin <http://phr.cx@NOSPAM.i nvalid>:
| "Donn Cave" <donn@drizzle.c om> writes:
|> Yes, it would be really weird if Python went that way, and the
|> sort of idle speculations we were reading recently from Guido
|> sure sounded like he knows better. But it's not like there aren't
|> some interesting issues farther on downstream there, in the compare
|> function. cmp(), and str() and so forth, play a really big role in
|> Python's dynamically typed polymorphism. It seems to me they are
|> kind of at odds with static type analysis
|
| I don't understand that. If I see "str x = str(3)", then I know that
| x is a string.

Sure, but the dynamically typed polymorphism in that function is
about its parameters, not its result. If you see str(x), you can't
infer the type of x. Of course you don't need to, in Python style
programming this is the whole point, and even in say Haskell there
will be a similar effect where most everything derives the Show
typeclass. But this kind of polymorphism is pervasive enough in
Python's primitive functions that it's an issue for static type
analysis, it seems to me, especially of the type inference kind.
cmp() is more of a real issue than str(), outside of the type
inference question. Is (None < 0) a valid expression, for example?

Donn Cave, donn@drizzle.co m

[Peter Dembinski]

Re: The Industry choice

Peter Dembinski <pdemb@illx.org > writes:

[...]
[color=blue]
> str = foo(x)[/color]

(ick!) it should be:

bar = foo(x)

[Peter Dembinski]

Re: The Industry choice

Peter Dembinski <pdemb@illx.org > writes:
[color=blue]
> Peter Dembinski <pdemb@illx.org > writes:
>
> [...]
>[color=green]
>> str = foo(x)[/color]
>
> (ick!) it should be:
>
> bar = foo(x)[/color]

Besides, shouldn't str be a reserved word or something?

[Peter Dembinski]

Re: The Industry choice

Bulba! <bulba@bulba.co m> writes:

[...]
[color=blue]
> The point is obviously "cover your ass" attitude of managers:[/color]

Managers get paid for taking risk :)

[Terry Reedy]

Re: The Industry choice


"Peter Dembinski" <pdemb@illx.org > wrote in message
news:87llbba55t .fsf@hector.dom ek...[color=blue]
> Besides, shouldn't str be a reserved word or something?[/color]

It is a name in the builtins module which is automatically searched after
globals. Many experienced Pythoneers strongly advise against rebinding
builtin names *unless* one is intentionally wrapping or overriding the
builtin object. The latter are sometimes valid expert uses of masking
builtins. Newbies are regularly warned on this list against making a habit
of casual use of list, dict, int, str, etc.

None has been reserved because there is no known good use for overriding
it. True and False will be reserved someday. There have been proposals to
turn on reserved status for all builtins on a per-module status.

Terry J. Reedy

[Alex Martelli]

Re: The Industry choice

Roy Smith <roy@panix.co m> wrote:
[color=blue]
> Stefan Axelsson <crap1234@hotma il.com> wrote:[color=green]
> > Yes, ignoring most of the debate about static vs. dynamic typing, I've
> > also longed for 'use strict'.[/color]
>
> You can use __slots__ to get the effect you're after. Well, sort of; it
> only works for instance variables, not locals. And the gurus will argue
> that __slots__ wasn't intended for that, so you shouldn't do it.[/color]

There's a simple, excellent recipe by Michele Simionato, on both the
online and forthcoming 2nd edition printed Cookbook, showing how to do
that the right way -- with __setattr__ -- rather than with __slots__ .


Alex

[Terry Reedy]

Re: The Industry choice


<beliavsky@aol. com> wrote in message
news:1104689464 .828070.309990@ c13g2000cwb.goo glegroups.com.. .[color=blue][color=green]
>> 2004-I: "xundef.f", line 2: 'y' is set but never used.[/color]
> 2005-W: "xundef.f", line 4: 'x' is used but never set.
> 2153-W: "xundef.f", line 5, column 1: Subscript out of range.[/color]

None of these are syntax errors. The first two of these would be caught by
lint or pychecker (I am presuming).
[color=blue]
> One reason interpreted languages like Python are recommended to
> beginners is to avoid the edit/compile/debug cycle. But I think it is
> faster and less frustrating to have many errors caught in one shot.[/color]

True syntax errors often result in such a cascade of bogus errors that it
may often be best to fix the first reported error and then recompile. Of
course, compilers vary in their recovery efforts.

Terry J. Reedy

[Terry Reedy]

Re: The Industry choice


"Bulba!" <bulba@bulba.co m> wrote in message
news:qcagt0l3u4 aou1le4phu257n6 embo98kv0@4ax.c om...[color=blue]
> On Sat, 01 Jan 2005 15:08:01 -0500, Steve Holden >[color=green]
>>whereas when a company goes
>>bust there's no guarantee the software IP will ever be extricated from
>>the resulting mess.[/color]
>
> There is a good _chance_ here: money. Somebody has poured a lot
> of money into this thing. It's not going to get dropped bc of that.[/color]
[color=blue]
>From what I have read, the amount of proprietary code which *did* get[/color]
effectively shredded after the dot-com bust is enough to make one cry.
There were a few companies that would buy code at bankruptcy sales for
maybe 1% of its development cost, but even then, with the original
programmers long gone, it could be hard to make anything from it.

Terry J. Reedy

[Roy Smith]

Re: The Industry choice

"Terry Reedy" <tjreedy@udel.e du> wrote:[color=blue]
> None has been reserved because there is no known good use for overriding
> it.[/color]

Should I infer from the above that there's a known bad use?
[color=blue]
> True and False will be reserved someday.[/color]

I remember a lisp I used many years ago. If you tried to rebind nil,
you got an error message -- in latin!

[Terry Reedy]

Re: The Industry choice


"Steve Holden" <steve@holdenwe b.com> wrote in message
news:_rTBd.6627 5$Jk5.46@lakere ad01...[color=blue]
> Well clearly there's a spectrum. However, I have previously written that
> the number of open source projects that appear to get stuck somewhere
> between release 0.1 and release 0.9 is amazingly large, and does imply
> some dissipation of effort.[/color]

And how do the failure and effort dissipation rates of open source code
compare to those of closed source code? Of course, we have only anecdotal
evidence that the latter is also 'amazingly large'. And, to be fair, the
latter should include the one-programmer proprietary projects that
correspond to the one-programmer open projects.

Also, what is 'amazing' to one depends on one's expectations ;-). It is
known, for instance, that some large fraction of visible retail business
fail within a year. And that natural selection is based on that fact that
failure is normal.

Terry J. Reedy