The Industry choice

[Cameron Laird]

.
.
.

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.

Let's provisionally assume ignorance rather than unintelligence,
if only on the grounds of parsimony. Sympathetic colleagues are
available, by the way, at <URL: http://www.engcorp.com/acf/ >.
While the Wiki remains *very* quiet, at this point, it's still
quite young.

The subject you raise is precisely at the middle of part of my
excitement about Python's prospects. I'll sketch the pertinent
propositions: GUIs are the wrong model; true flexibility involves
a domain-specific, well-designed "little language". "Scripting
languages" were originally "configuration languages"; return to
those roots is only healthy. Scientific and engineering software
particularly has been in thrall to the GUI, and deserves rejuve-
nation with "scripting". Key to the dynamic of dynamic languages
is that they make it cheaper to re-write than to re-use, in some
carefully limited sense.

I've seen the infatuation for Excel (and so on) for years, but
never found it at all tempting myself. I mostly just ignore the
issue--no, actually, I guess I give them Excel, but show at the
same time that they really want the alternative views that I
also provide.

 

[John Roth]

.
.
.
....

You might want to read this:

http://alistair.cockburn.us/crystal/articles/teoseatsoecg/theendofsoftwareengineering.htm

His thesis is very simple: engineering took a wrong turn after
WW II, and the people who coined the term "software engineering"
didn't have a clue.

Of course, he puts it a bit more diplomatically, but he's
got the data to demonstrate that software engineering
is an oxymoron.

John Roth

 

[Steve Holden]

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.

Well, since everything you say is true, I suppose there's not much
wriggle room for me.

But when a shop goes belly up, it's most often replaced by another
business in fairy short order, and proprietary project failures are
usually hushed up by firing the programmers and promoting the managers.

Whereas the bleached bones of the failed open source projects are
visible for all to see on the SourceForge beach.

regards
Steve

 

[Steve Holden]

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.

The road to hell is paved with good intentions.

regards
Steve

 

[Stephen Waterbury]

Aahz wrote:
I was pretty skeptical of Java's checked exceptions when I first used
them but have been coming around about them. [...]

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.

Pretty sloppy, though, no? And surely the important thing is to have
a broad handler, not a broad specification of raisable exceptions?

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.

The road to hell is paved with good intentions.

Hmm ... those must be what my bucket keeps bumping over!

Steve W.

 

[Aahz]

The road to hell is paved with good intentions.

So's the road to unfinished software projects. The question, as always,
becomes how best to balance the competing requirements and resources.

 

[Peter Hansen]

Whereas the bleached bones of the failed open source projects are
visible for all to see on the SourceForge beach.

It occurs to me that the value of those projects can be judged
in a number of ways. One of them is in how much those involved
in the projects have learned from the experience. Perhaps one
rarely starts a second open source project with quite as much
rabid, unthinking enthusiasm as one did the first time around,
and maybe the world is a better place for it.

I know that I've started many one-man projects over the years,
and only slowly (I'm a little thick, you see) came to realize
that while it's incredibly easy to start something, seeing it
through to the end is rather more difficult.

At this point, perhaps largely as a result of a new world-view
inspired by the agile movement, I rarely start anything...
and when I do, it's driven by a strong, recurring need, and I
only do just enough to meet that need, in the simplest way
I can find. (Often, that ends up not involving a computer.)

-Peter

 

[Tim Churches]

I've seen the infatuation for Excel (and so on) for years, but
never found it at all tempting myself. I mostly just ignore the
issue--no, actually, I guess I give them Excel, but show at the
same time that they really want the alternative views that I
also provide.

See http://www.burns-stat.com/pages/Tutor/spreadsheet_addiction.html for
a thoughtful essay by a statistician on this affliction. I think that
Python would be an excellent addition to his Treatment Centre pharmacopoeia.

Tim C

 

[Rob Emmons]

Theoretically. Because even though the source code is available

and free (like in beer as well as in speech) the work of
programmers isn't cheap.

This "free software" (not so much OSS) notion "but you can
hire programmers to fix it" doesn't really happen in practice,
at least not frequently: because this company/guy remains
ALONE with this technology, the costs are unacceptable.

This certainly is the thinking, but I is the wrong thinking in many cases.
If companies could some how take a larger view and realize that by working
together here and there -- they enable and open development model which in
the end saves them money. AHHH but that's such a hard argument because it
takes vision, time, and trust.

It takes a whole vision change to work in this environment -- believing in
an economy of plenty rather than an economy of scarcity.

It depends on definition of "rational", on definition of your or
company's goals and on the definitions of the situations that
are the context.

I work for a very large company -- there is an internal culture that
defines what "rational" is: (a) Rational means outsourcing and doing less
inside the company, (b) pretty much single sourcing commerical software,
(c) releasing nothing outside the company unless there is a direct
demonstratable significant business benifit related to our core products.

I could argue these are not rational in the long run, but this is
the direction of the company as far as I know. This will change -- and
someone will get a big promotion for doing it -- but it will take a lot of
time. And of course someone already got a big promotion for outsourcing
and developing the single source stratagy -- bone headed as it is.

Rob

 

[Mark Carter]

> Cameron Laird wrote:
>

True story: when I began working for my current employer, there was a
guy there doing some work with a spreadsheet. He was given two weeks to
perform the task. It was a loss-leader to get some real work from the
client.

There already existed a spreadsheet, which did financial projections. It
used VBA fairly extensively, and his task was to adapt it to remove the
VBA code. This means converting things like functions into equivalent
cell formulae. The rationale behind this is that VBA is too hard for
most people to understand, whereas formulae are easier to understand.
Conditionals look really confusing in formulae, and I don't know how he
coped with loops. And then, of course, you have to replicate them to
every cell that requires them. Can you imagine that? Is this very the
definition of madness, or what?

The whole thing was a gigantic spreadsheet (I can't remember, it was
either 9Mb or 90Mb in size), and kept crashing every few minutes. Utter
utter insanity. Whenever he went back the client, she demanded
improvements. We had effectively told her that she could have whatever
whe wanted. And oh, it would only take 2 weeks. The managers never
pulled the plug on the project.

Apparently, our guy sat in on a conversation that the client had with a
potential contractor who would replace the spreadsheet. His first
question was, surprise surprise, "why on earth did you try to do it that
way?"

The thing is, our guy was scheduled to be booted out the door because he
was in a business area that was being discontinued by us, so from my
employer's point-of-view, I guess that all this lunacy actually made sense.

 

[michele.simionato]

But then I have THREE published recipes!!
Does that mean that I get three free copies of the cookbook ? ;-)
Michele

 

[Kent Johnson]

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__ .

The recipe is here (it took me a few minutes to find it, I found the title misleading):
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/252158

Kent

 

[Cameron Laird]

.
.
.

True story: when I began working for my current employer, there was a
guy there doing some work with a spreadsheet. He was given two weeks to

.
[tale of atrocity and woe]
.
.

cell formulae. The rationale behind this is that VBA is too hard for
most people to understand, whereas formulae are easier to understand.

.
.
.
Well *that* certainly made my morning unpleasant.

I think the point to take away has something to do with maturity
or judgment or one of those other difficult qualities. Some of
this stuff--"formulae are easy to understand", "you don't need
programmers, you just enter what you want the machine to do",
"we'll wage war on terrorists by *becoming* terrorists", "Micro-
soft has spent more on 'security' than any other vendor"--*sounds*
like a useful guide to action. A hard part of our responsibility,
though, is articulating for decision-makers that these superficial
simplificities truly are superficial, and that they lead to
monstrous costs that are hard for "civilians" to anticipate.

 

[Mark Carter]

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, first visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

> Well *that* certainly made my morning unpleasant.

Then let's see if I can spoil you afternoon, too ...

I was working on a project (that used Excel, alas) that checked the
daily allocation of oil and gas. The calculations were very complicated,
and liable to error. I thought it would be a good idea if I serialised
intermediate calculations so they could be checked. My solution was to
save them as a CSV file, with array name in the first column, index
variables in subsequent columns, and array value in the last column.
That way, they could be checked manually. The standard approach at my
company would have been to create honking big spreadsheets to house
these values.

Anyway, time went on, it was decided that these daily calculations
needed to be aggregated to monthly values. Well, it turned out that the
solution I had adopted was quite good, because one could just suck the
file in, read off the relevant variables, and populate an array. To be
compared with what would normally happen of creating a nexus of links to
a disk-busting collection of spreadsheets.

I shall have my revenge, though. The file serve hierarchy that we have
is very complicated, and is due for simplification in the very near
future. So all those peeps who did spreadsheets, with hard links to
other spreadsheets, are in for a bit of a surprise. I think the I-Ching
expressed it better than I ever could:
The bird's nest burns up.
The wanderer laughs at first,
Then must needs lament and weep.
Through carelessness he loses his cow.
Misfortune.

Source:
http://www.eclecticenergies.com/iching/hexagram.php?nr=56

I'm thinking that the I-Ching is a vast untapped resource for
programming wisdom, plus it makes it funny. Or haikus, maybe they'd be
good.

 

[Cameron Laird]

.
.
.

def foo(x):
return str(x)

str = foo(x)

And now, let's say that foo()'s definition is in another module.
It is hard for a programmer to quickly determine the type for str,
that's the problem with programming in languages that don't have
type declarations.

I think I don't understand. I believe you're saying that Python and
C might code homologously as

def py_foo(x)
return py_bar(x)

and

char *C_foo(int x)
{
return C_bar(x);
}

and that these definitions make it evident that C_foo() returns a
(char *), while there's no such manifest restriction on the type
of py_foo(). Well, yes, that's so (but what did it have to do with
definitions in another module?). There's nothing peculiar in this
to functions, right? Python declares types of *no* bindings, so
your claim is equally true of local variables, correct?

And this is all a *benefit* of Python, at least as I see it. Yes,
good style in Python is different from good style in C, but the
former's strong implicit typing has, I think, equal claim to
virtue.

Type in C are so epiphenomenal. They communicate little of what *I*
need to know.

 

[Cameron Laird]

In practice I have *never* worked on an industrial scale project
that only used one language. The nearest I came was a small
protocol convertor that only used C, SQL and some shell and
awk - but that's still 4 languages! And the whole project was
only 40,000 lines of code in about 20 files.

And most projects use many more, I'd guess around 5-8 on an
"average project" of around 300-500kloc. The biggest project I
worked on had about 3.5Mloc and used:

Assembler (680x0 and Sparc),
C
C++
Lisp(Flavors)
awk
Bourne shell
C shell - this was a mistake discovered too late to "fix"
PL/SQL
???? - A UI description language for a tool called TeleUse...
Pascal - No, I don't know why...
ASN.1 - with a commercial compiler

We also had some IDL but since it was tool generated I'll ignore
it...

We also had an experimental version running on a NeXt box so it
used Objective C for the UI instead of ???? and C++...

A total of 13 languages... with 5 geographically dispersed teams
comprising a total of 200 developers (plus about 40 testers).
Interesting times...in the Chinese sense!

.
.
.
D. The TeleUSE language <URL: http://www.aonix.com/teleuse.html > is "D".

And I suspect your count is a lower bound. If you worked with TeleUSE,
somebody probably was doing Motif configuration, which arguably is a(n
impoverished configuration) language itself.

 

[Alex Martelli]

But then I have THREE published recipes!!
Does that mean that I get three free copies of the cookbook ? ;-)

....ti piacerebbe eh...?-) Sorry, "one each", even though you have
_five_ credits. For the curious, here's the roster of most credited
contributors (remember, significant comments we merged into other's
recipes also count!-)...:

1: 42 u'Alex Martelli'
2: 26 u'Raymond Hettinger'
3: 25 u'Luther Blissett'
4: 22 u'Peter Cogolo'
5: 10 u'John Nielsen'
6: 10 u'Anna Martelli Ravenscroft'
7: 8 u'J\x9frgen Hermann'
8: 7 u'Scott David Daniels'
9: 7 u'Chris Perkins'
10: 6 u'S\x8ebastien Keim'
11: 6 u'Paul Prescod'
12: 6 u'Noah Spurrier'
13: 6 u'Jeff Bauer'
14: 6 u'Holger Krekel'
15: 6 u'Danny Yoo'
16: 6 u'Brent Burley'
17: 5 u'Paul Moore'
18: 5 u'Michele Simionato'
19: 5 u'Mark Nenadov'
20: 5 u'David Eppstein'
21: 5 u'Brian Quinlan'

If you wished to count only _authored_ recipes (but that's a bit
misleading, since in several recipes-as-published there is a merge of
two or three separately submitted and accepted recipes, and here I'm
counting only the first-listed-author per published-recipe...):

1: 25 u'Luther Blissett'
2: 21 u'Alex Martelli'
3: 9 u'John Nielsen'
4: 8 u'Raymond Hettinger'
5: 8 u'J\x9frgen Hermann'
6: 6 u'S\x8ebastien Keim'
7: 6 u'Peter Cogolo'
8: 6 u'Anna Martelli Ravenscroft'
9: 5 u'Scott David Daniels'
10: 5 u'Paul Prescod'
11: 5 u'Michele Simionato'
12: 5 u'Mark Nenadov'
13: 5 u'Jeff Bauer'
14: 5 u'Brent Burley'

....but each still gets ONE free copy...!-)


Alex

 

[Mark Carter]

I'm thinking that the I-Ching is a vast untapped resource for
programming wisdom, plus it makes it funny.

Well, carrying on in the same frivilous and some might say off-topic
mood, I did a bit of a Google, and found that you can generate your very
own I-Ching reading:
http://www.grillet.co.uk/iching/

According to the link at:
http://www.grillet.co.uk/iching/casting.html
"The I Ching is a good guide in taking decisions when you have no
rational basis on which to take them." So if your project manager comes
out with something like "A pot upturned to empty the decay. The superior
one attends to the Way of Heaven.", you'll know whence he's distilling
his madness.

 

[Premshree Pillai]

Do contributors of less than 5 recipes get a copy too? :-?

Btw, is there a comprehensive list of ALL contributors put up anywhere?

 

[Christopher Koppler]

;; This buffer is for notes you don't want to save, and for Lisp evaluation.
;; If you want to create a file, first visit that file with C-x C-f,
;; then enter the text in that file's own buffer.

Now, _where_ have I seen that before?

I'm thinking that the I-Ching is a vast untapped resource for
programming wisdom, plus it makes it funny. Or haikus, maybe they'd be
good.

If only all error messages were like that:

Through winter's freezing
Nature dies to live again
You need to debug