Python for large projects

[Jacek Generowicz]

Stefan Axelsson <crap1234 at hotmail.com> writes:

> Jacek Generowicz wrote:
> 
> Please also note that I'm by no means trying to change your opinion
> on the matter,

The thought never crossed my mind.

> I see this more as a panel style debate.

Indeed.

> > Forgive me if I am wrong ... but typeful programming is more of a
> > programming style rather than a property of a (static) type system, is
> > it not? I realize that Haskell encourages typeful programming by its
> > very nature, but that doesn't make typeful programming an property of
> > the type system.
> 
> Yes, it's not really a requirement of the type system.

> In fact dynamic typing can be simulated by a polymorphic static type
> system (I haven't got the reference handy, follow up if you're
> interested),

If you happen to find it, drop me a line, please. (Don't go too far
out of your way though ... my stack of interesting things I want to
read is mostly monotonically growing :-( )

> The same is true of unittesting as you go, though, there's nothing
> in dynamic typing to enforce it.

Of course. I never intended to imply that test suites are some sort of
magic. They require hard work to build and maintain, but it is work
which is well worth the investment, in my experience. But, in my
experience, they are also harder to write in (explicitly) statically
typed languages. (And it is my perception that many people believe
that static typing systems will do for them, for free, that which, in
reality, they have to do for themselves with the help of test suites.)

(Sorry for being repetitive, but my teaching experience tells me that
people often need repeated exposure to the same idea, to help it sink
in, and I'm hoping that there are some lurkers who might be
susceptible to indoctrination :-)

> But the interesting point is whether static type systems somehow
> magically makes good programmers from bad, and that's not true
> IMHO.

Well, yes, that would indeed be magic :-)

> That's not to say that I prefer a bad programmer from having a
> static type system, the more hurdles you place in the way of the truly
> bad programmers of which industry is chock full (as a student of mine
> with experience from industry once exclaimed: "But most programmers
> are BAD!"). I'm talking about any type of static type system here,
> while I'd say that the type system of 'C' isn't that much of
> hinderance to the gifted, it decreases the productivity of the clods
> to managable proportions (I'm talking about the programmers with
> negative productivity here).

I'm ambivalent about this point. On the one hand I share your view; on
the other I think that removing the irrelevant obstacles that
(explicit) static typing systems create, would actually make quite a
few previously negatively productive programmers become positively
productive.

Heh, now it might sound like I'm saying "dynamic typing magically
makes good programmers from bad". I'm not. I'm saying that static
typing systems make most programmers less productive ... and if your
productivity is around zero, then the rigidity of the type system
could well be the difference between + and -.

> In this setting I'd say that Java is a win,

You mean "damage limitation" and enabling "primate programming"
(http://www.newtechusa.com/ppi/main.asp) ?  Yes, that's the whole
purpose of Java, as far as I can see.

> I've found that any enforcement mechanism helps. The harder it
> becomes to skirt the requirements of the process the more it will be
> followed.

Maybe I'm being naive, but I (want to) believe that programming is a
highly skilled activity, pursued by dedicated and creatively
intelligent practitioners. Following process requirements is not the
way to get the best results, in that case. If by programming you
understand "primate programming", then straitjacketing is necessary, I
agree.

> A type system has an advantage here in that it *cannot* be
> circumvented while it's trivial to write no or bad unit test so that
> you can ship your code to the integration step.

Again, difference in philosophy. I assume that I am trying to write
the best product I can. Writing bad tests is not in my interest. I
acknowledge that this is probably not the case in most real-life
situations.

Conclusion: I'm naively, romantically optimistic about what
programming is :-)

> It's interesting to note that Ericsson drew the conclusion that C++
> was to blaim for the failed billion dollar AXEn project. Of course the
> choice of language had very little to do with that.

But that won't deter me from quoting it to all and sundry :-)

(Do you have a reference to this conclusion ?)