... and a number of firms on Wall Street are killing off their IM services, and even blocking them on internal firewalls, because some judge has determined that IMs have to be preserved just as emails do.
Let's consider serious programming first: I think Brooks' points really make excellent sense for things like kernel programming, building high-performance application servers, etc -- real systems progamming. The issues here are just not that it takes too long to express the idea in code -- the problem is figuring out the freakin' answer. (And take as read the rant about how just because programmers write code, it doesn't mean everyone who writes code is really a programmer.)
On the other hand, visual programming of various sorts, specialized to a particular problem domain, is a major advantage, and your example of spreadsheets is a perfect one. I used to maintain a program for making quick changes and test runs on a balance sheet. It was many many lines of APL, and it worked pretty well (and if I had just made a single conceptual step, I would have invented the spreadsheet. Damn.)
Now, these applications are built, in minutes, by people who would never think they were programming at all. All by using what Ben Shneiderman calls a "direct manipulation" interface. But what they are effectively doing is programming.
Oh, come on, this is silly. If the name space is in any way visible to the compiler, then matching the regular expression 'java.*Date' is not significantly harder than 'java\.util\..*' -- and if the name space is not visible to the compiler, then no import scheme will work.
... and we therefore discover that the semantics of import are tightly coupled to the notion of a hierarchical file system -- which was the point, wasn't it?
First, unfortunately, the package name does not represent just a name space to the compiler. javac as distributed by Sun, and every other implementation of Java I'm aware of (with the exception of the late lamented Visual Age for Java), requires the package naming structure to correspond 1-1 with a path tree structure.
You're misunderstanding the namespace notion a bit though: If I import java.util.Date, I'm not adding a namespace, I'm adding a name to my current namespace or scope. import java.util.* might be thought of as importing a name space, or at least adding a collection of fully qualified names to the current name space. But if we see a wildcarded import that way, why shouldn't import java.*.Date bring both names into the name space? (Answer: because they'd still have to be referred to by fully-qualified names. But then, since there is no difference, why make it a syntax error?)
The point here is that Java purports to construct a hierarchically-organized namespace, but doesn't actually do so. (Thought experiment: what's the effective difference between import com.foo.bar.* and import com-foo-bar.*? Ans: none except that you don't have to have a directory tree four deep for your sources.)
Oh, and as far as your ls point: don't try to teach Grandma to suck eggs, son.
That's my experience too: I tend to draw the early versions, especially when you have to twiddle it a lot for the customer, and then re-code it by hand afterwards to get it to, as you say, sing and dance.
But most UIs have great chunks that are pretty static.
Sorry, I didn't mean to give the impression I was particularly against Ada. I was very much on Ada's side, starting with Strawman. But it had some real flaws in the 83 version, which were mostly the result of specific weakenings of the semantics to make sure everyone liked it. The one that annoyed me most was task/rendezvous, which didn't (sorry) define the behavior of tasks at all well. In fact, a program could pass the Ada test suite if it didn't implement task concurrently at all, as I recall.
Ada 95 improved that a good bit -- I was involved slightly with the Ada 9x stuff, and one of the things we were struggling with was getting some things well-defined that previously weren't well defined. But part of the reason Ada95 was 12 years after Ada83 is that, having let it get out in the 83 form, it was really difficult to strengthen those expectations, because it would break existing code.
It's a lot easier to make sure to think these things out first try.
Yes, exactly. But why? Since it looks so much like a path name (and represents a pathname to the compiler), why doesn't it do the same thing as ls foo/*/CVS, say?
The cite could be wrong -- I was scrounging quickly on the net. In fact, thinking about it, it's almost certainly wrong, because the paper came out when I was in grad school, and I started in '83.
Concurrency as in multitasking/multithreading? It's really easy in Ada, and it works quite well everywhere I've used it.
The problem isn't that it works badly, necessarily -- it's that it doesn't work the same way everywhere. At least as of Ada 83, the semantics of a task were't the same from machine to machine. Made it a real bear to reason about the behavior of an Ada program.
I actually did my PhD and Masters' work with the idea originally being to develop a visual or direct-manipulation (see Ben Schneiderman's stuff if you don't know the term) programming environment. You know what happened? I went to Fred Brooks' original "No Silver Bullet" presentation (see the paper to see the details) and found that I couldn't manage to refute his arguments. (I hate it when that happens.:-)
The basic argument is this: are the complexities of notation (language, whatever) essential or accidental aspects of the difficulties in programming? Brooks' argument is that the notation is an accidental issue -- that you can't gain, say, an order of magnitude improvement by chaning notation alone.
This is clearly not 100 percent true 100 percent of the time -- "drawing" a GUI with something like Powerbuilder, Eclipse, or JBuilder is clearly a lot more effective than coding it, even with EMACS. On the other hand, in real industrial development, actual coding is only about 15 percent of the total time and cost invested -- so no matter how wonderful the language is, it can't possibly account for more than about a 15 percent improvement.
Oh, just in case I misuinderstood -- there are languages which get a lot of the details right -- eg, Occam makes a pretty good job of defining a semantics for a limited model of concurrency based on Hoare's Communicating Sequential Processes.
Sadly, not offhand. But a significant step toward getting it right is by defining a semantics -- which is a step that Ada missed out on (at least in the original Ada, I've not had the moral strength to learn much about Ada95) and a weakness of Java as well.
First thing: read Tony Hoare's critique of Ada. (CAR Hoare, Hints on Programming Language Design, 1978). All the current common languages are way too complex.
Second, make sure the language has a formal semantics from the start. This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java,...) in the last 20 years that decided this was just too hard, and eventually paid for it.
Third, make sure that the notation either explicitly uses files, or is completely independent of files. Probably the most annoying aspect of Java is that the package structure implicitly depends on a directory hierarchy (but some OS's don't have hierarchic file systemss) but doesn't deal with package structure in anything like the way hierarchic file systems do (what does 'import java.*.event' mean?)
Fourth, write a lot of sample programs, and test each with experienced programmers, saying 'what does this program do?' If the programmer doesn't get it approximately right, rethink the syntax.
I agree that basing arguments on the work on Michael Moore can be dangerous, but I don't think his characterization of Americans as paranoid gun nuts was too far off the mark.
Yes. He manufactured situations, constructed speeches out of things that happened months apart and put them into contexts in which they didn't belong. As I just said to someone else, I was physically present at some of these events and can confirm that the Hardylaw site is correct where Moore's flic isn't.
If you can't cope with that, perhaps you need to get out of the kitchen.
Don't take Bowling for Columbine as evidence of much anything: those of us who live out by Columbine know that Moore -- how to put this? -- oh, I know: lied.
BY this reasoning, if Micrososft sold an empty box they'd be justified in selling updates to add value by doing something they advertised.
When the updates aren't primarily about removing exploitable buffer overflows, and Windows variants don't crash daily or worse, they might have an argument -- but right now I'm damned if I want to see then charging for "features" that are just normal decent practice in any other company.
Slashdot Mirror
... and a number of firms on Wall Street are killing off their IM services, and even blocking them on internal firewalls, because some judge has determined that IMs have to be preserved just as emails do.
They never would be missed.
You're on a good couple of points here.
Let's consider serious programming first: I think Brooks' points really make excellent sense for things like kernel programming, building high-performance application servers, etc -- real systems progamming. The issues here are just not that it takes too long to express the idea in code -- the problem is figuring out the freakin' answer. (And take as read the rant about how just because programmers write code, it doesn't mean everyone who writes code is really a programmer.)
On the other hand, visual programming of various sorts, specialized to a particular problem domain, is a major advantage, and your example of spreadsheets is a perfect one. I used to maintain a program for making quick changes and test runs on a balance sheet. It was many many lines of APL, and it worked pretty well (and if I had just made a single conceptual step, I would have invented the spreadsheet. Damn.)
Now, these applications are built, in minutes, by people who would never think they were programming at all. All by using what Ben Shneiderman calls a "direct manipulation" interface. But what they are effectively doing is programming.
Oh, come on, this is silly. If the name space is in any way visible to the compiler, then matching the regular expression 'java.*Date' is not significantly harder than 'java\.util\..*' -- and if the name space is not visible to the compiler, then no import scheme will work.
As a database fan, I say farm concurrency off to the database...
But, as someone or other undoubtedly said, quis custodiet ipsos databases? Someone has to write the damned things.
(Plus, there are a lot of things other than databases which need concurrency control, eg, an operating system kernel.)
1. Languages should be complex. Life is complex.
I kinda was hoping for something that wasn't as much of a pain in the ass as the rest of my life.
BTW, I just downloaded Mozart/Oz and am building it as we speak. Looks fascinating. Thanks.
... and we therefore discover that the semantics of import are tightly coupled to the notion of a hierarchical file system -- which was the point, wasn't it?
You're missing the point in a couple of ways.
First, unfortunately, the package name does not represent just a name space to the compiler. javac as distributed by Sun, and every other implementation of Java I'm aware of (with the exception of the late lamented Visual Age for Java), requires the package naming structure to correspond 1-1 with a path tree structure.
You're misunderstanding the namespace notion a bit though: If I import java.util.Date, I'm not adding a namespace, I'm adding a name to my current namespace or scope. import java.util.* might be thought of as importing a name space, or at least adding a collection of fully qualified names to the current name space. But if we see a wildcarded import that way, why shouldn't import java.*.Date bring both names into the name space? (Answer: because they'd still have to be referred to by fully-qualified names. But then, since there is no difference, why make it a syntax error?)
The point here is that Java purports to construct a hierarchically-organized namespace, but doesn't actually do so. (Thought experiment: what's the effective difference between import com.foo.bar.* and import com-foo-bar.*? Ans: none except that you don't have to have a directory tree four deep for your sources.)
Oh, and as far as your ls point: don't try to teach Grandma to suck eggs, son.
That's my experience too: I tend to draw the early versions, especially when you have to twiddle it a lot for the customer, and then re-code it by hand afterwards to get it to, as you say, sing and dance.
But most UIs have great chunks that are pretty static.
Sorry, I didn't mean to give the impression I was particularly against Ada. I was very much on Ada's side, starting with Strawman. But it had some real flaws in the 83 version, which were mostly the result of specific weakenings of the semantics to make sure everyone liked it. The one that annoyed me most was task/rendezvous, which didn't (sorry) define the behavior of tasks at all well. In fact, a program could pass the Ada test suite if it didn't implement task concurrently at all, as I recall.
Ada 95 improved that a good bit -- I was involved slightly with the Ada 9x stuff, and one of the things we were struggling with was getting some things well-defined that previously weren't well defined. But part of the reason Ada95 was 12 years after Ada83 is that, having let it get out in the 83 form, it was really difficult to strengthen those expectations, because it would break existing code.
It's a lot easier to make sure to think these things out first try.
Yes, exactly. But why? Since it looks so much like a path name (and represents a pathname to the compiler), why doesn't it do the same thing as ls foo/*/CVS, say?
VBA is isn't horrible.
Yes it is.
I thought it was in his 1981 speech, ....
The cite could be wrong -- I was scrounging quickly on the net. In fact, thinking about it, it's almost certainly wrong, because the paper came out when I was in grad school, and I started in '83.
Concurrency as in multitasking/multithreading? It's really easy in Ada, and it works quite well everywhere I've used it.
The problem isn't that it works badly, necessarily -- it's that it doesn't work the same way everywhere. At least as of Ada 83, the semantics of a task were't the same from machine to machine. Made it a real bear to reason about the behavior of an Ada program.
I actually did my PhD and Masters' work with the idea originally being to develop a visual or direct-manipulation (see Ben Schneiderman's stuff if you don't know the term) programming environment. You know what happened? I went to Fred Brooks' original "No Silver Bullet" presentation (see the paper to see the details) and found that I couldn't manage to refute his arguments. (I hate it when that happens. :-)
The basic argument is this: are the complexities of notation (language, whatever) essential or accidental aspects of the difficulties in programming? Brooks' argument is that the notation is an accidental issue -- that you can't gain, say, an order of magnitude improvement by chaning notation alone.
This is clearly not 100 percent true 100 percent of the time -- "drawing" a GUI with something like Powerbuilder, Eclipse, or JBuilder is clearly a lot more effective than coding it, even with EMACS. On the other hand, in real industrial development, actual coding is only about 15 percent of the total time and cost invested -- so no matter how wonderful the language is, it can't possibly account for more than about a 15 percent improvement.
Oh, just in case I misuinderstood -- there are languages which get a lot of the details right -- eg, Occam makes a pretty good job of defining a semantics for a limited model of concurrency based on Hoare's Communicating Sequential Processes.
Sadly, not offhand. But a significant step toward getting it right is by defining a semantics -- which is a step that Ada missed out on (at least in the original Ada, I've not had the moral strength to learn much about Ada95) and a weakness of Java as well.
First thing: read Tony Hoare's critique of Ada. (CAR Hoare, Hints on Programming Language Design, 1978). All the current common languages are way too complex.
...) in the last 20 years that decided this was just too hard, and eventually paid for it.
Second, make sure the language has a formal semantics from the start. This semantics needs to include concurrency and how it works. I can think of half a dozen languages (Ada, C++, Java,
Third, make sure that the notation either explicitly uses files, or is completely independent of files. Probably the most annoying aspect of Java is that the package structure implicitly depends on a directory hierarchy (but some OS's don't have hierarchic file systemss) but doesn't deal with package structure in anything like the way hierarchic file systems do (what does 'import java.*.event' mean?)
Fourth, write a lot of sample programs, and test each with experienced programmers, saying 'what does this program do?' If the programmer doesn't get it approximately right, rethink the syntax.
One of the most fascinating things about the Web is that you can find someone who believes any silly-ass theory.
It's a lovely theory that's only slightly spoiled by the fact that even a casual observer can tell a limestone block from concrete.
But thank you for playing.
I agree that basing arguments on the work on Michael Moore can be dangerous, but I don't think his characterization of Americans as paranoid gun nuts was too far off the mark.
Smile when you say that, partner.
Yes. He manufactured situations, constructed speeches out of things that happened months apart and put them into contexts in which they didn't belong. As I just said to someone else, I was physically present at some of these events and can confirm that the Hardylaw site is correct where Moore's flic isn't.
If you can't cope with that, perhaps you need to get out of the kitchen.
I can confirm, having been physically present at some of thse events, that the Hardylaw site is a damn sight closer to the truth than Moore's flic.
Don't take Bowling for Columbine as evidence of much anything: those of us who live out by Columbine know that Moore -- how to put this? -- oh, I know: lied .
More here.
BY this reasoning, if Micrososft sold an empty box they'd be justified in selling updates to add value by doing something they advertised.
When the updates aren't primarily about removing exploitable buffer overflows, and Windows variants don't crash daily or worse, they might have an argument -- but right now I'm damned if I want to see then charging for "features" that are just normal decent practice in any other company.