Developer Soup (Software Carpentry, Python, Eiffel, KDevelop)

[Warren Postma]

This is sort of related to gwilson's thread regarding "python books that
need writing", but it's more about his Software Carpentry contest, and his
article (http://www.oreilly.com/news/vhll_1299.html) which critiques VHLLs.

First, I'm intrigued by Eiffel's Programming by Contract. Can anyone
enlighten me on this subject, or post some links?

It seems to me that Components are more to the point than "contracts", and
that contracts are a useful part of the whole picture of components.  So
what is Python doing about Component driven programming?  I'll tell you
something I miss from Delphi, which is a key part of Delphi's component
style.

Let's imagine I could do this in Python:

# centipede has
#        constraint on attributes, legs must be between 0 and maxlegs, and
must be an even number.
class centipede:
        legs in range(0,maxlegs),check_even(self)
        color in centipede_color_set
        def check_even(self):    # any function can be added as a constraint
check
                if (self.legs % 2) == 0:
                        return 1
                return 0

Also, let's imagine I could go ahead an add pre and post conditions to
methods in Python would that be a good idea?

I sure would like the idea of building a component and specifying it's
interface (the interface section a la Pascal and Modula 2) and some more
general support for information hiding, and I'd also really like to have
Delphi's idea of "properties" as part of objects. A property is a virtual
attribute (with a hidden private data member) with both a get and set method
which are transparentely accessed when I read or write to "centipede.legs".
I've seen some stuff on this list about __getattr__ and __setattr__ and this
seems like quite a hack.


What the World Needs Now:

Frankly, Python is the first new discovery I've made since "Delphi 1.0" in
1995 that promises to add really useful stuff to my programming toolbox.
While I balked at the tabbed-scope stuff initially, I got over that (it was
a 2 beer problem) and I now officially love Python.

Yet, I am one of those programmers Mr. Wilson refers to who in general will
silently veto anything new unless I see the benefit of it in short order. I
am especially cynical about anyone who wants me to renounce my existing
toolset and start over.

While I agree with Mr. Wilson's "Software Carpentry" ideal, and avoiding
'accidental complexity', it seems to me that the $850K being spent on
resuscitating these crusty old Unix command line tools (chiefly make,
autoconf, and automake) to make new command line tools is a perfect example
of the things he criticizes in programmers like me.

I think it would be far better to invest in building tools to plug into an
already started new development environment. After all, "It's not the 70s
anymore Dorothy".

KDevelop is clearly in the lead as a portable cross-platform IDE, and I
think $850K could do a lot to help it along. Once people are writing their
software in a world-class IDE, instead of sitting in Bash, vi and EMACS all
day, I think we would safely be able to say that Unix had caught up to the
Windows platforms of the late 1990s.  Let's at least be realistic, folks.

Then all we have to do is make the whole thing really hum is Pythonize
KDevelop to the core. :-)

Warren Postma