Re: How can engineers not understand source-code control?
On Tue, 04 Jan 2005 15:52:03 +, Mark Carter <[EMAIL PROTECTED]> wrote: > I'm thinking that the I-Ching is a vast untapped resource for > programming wisdom, plus it makes it funny. LOL! +1 QOTW! -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
On Tue, 04 Jan 2005 15:52:03 +, Mark Carter wrote: > ;; 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 -- Christopher 99 bottles of Snakebite on the wall... -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
Mark Carter wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
;; 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. Cameron Laird wrote: > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
In article <[EMAIL PROTECTED]>, Mark Carter <[EMAIL PROTECTED]> 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 . [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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
> Cameron Laird wrote: > >> I've seen the infatuation for Excel (and so on) for years, 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control?
Cameron Laird wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: How can engineers not understand source-code control? (was: The Industry choice)
In article <[EMAIL PROTECTED]>, Mark Carter <[EMAIL PROTECTED]> wrote: . . . Don't start me! Dammit, too late ... ... Honestly, I thought (real) engineers were supposed to be clever. 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 -- http://mail.python.org/mailman/listinfo/python-list
How can engineers not understand source-code control? (was: The Industry choice)
In article <[EMAIL PROTECTED]>, Mark Carter <[EMAIL PROTECTED]> wrote: . . . >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 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. -- http://mail.python.org/mailman/listinfo/python-list
