From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: in defense of GC References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1mahvxskejxe1$.tx7bjdqyo2oj$.dlg@40tude.net> <2tfy9vgph3.fsf@hod.lan.m-e-leypold.de> <1g7m33bys8v4p.6p9cpsh3k031$.dlg@40tude.net> <14hm72xd3b0bq$.axktv523vay8$.dlg@40tude.net> <4zwt33xm4b.fsf@hod.lan.m-e-leypold.de> <1j7neot6h1udi$.14vp2aos6z9l8.dlg@40tude.net> <1170838486.7656.7.camel@localhost.localdomain> <1170891160.30084.116.camel@localhost> From: Markus E Leypold Organization: N/A Date: Thu, 08 Feb 2007 10:24:35 +0100 Message-ID: <1ktzxxuhm4.fsf@hod.lan.m-e-leypold.de> User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:9Ec04e5qWx2Es6jnqr5noN3hjMA= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.239.230 X-Trace: news.arcor-ip.de 1170926366 88.72.239.230 (8 Feb 2007 10:19:26 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news2.google.com!news4.google.com!news1.google.com!news.germany.com!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news2.google.com comp.lang.ada:9184 Date: 2007-02-08T10:24:35+01:00 List-Id: Georg Bauhaus writes: > On Wed, 2007-02-07 at 12:19 +0100, Markus E Leypold wrote: >> Georg Bauhaus writes: >> > >> > If you do this, perhaps you can find the time to use a, uh, stop-watch >> > to measure the time it takes to produce, read, and change the programs? >> > I.e., to technically manage significant software. The times will be >> > important input for deciding whether or not static typing does indeed >> > help in production. >> > The only thing that relates to economic efficiency, if you want it :-) >> >> So the how long a beginner in a specific language takes to do >> something is "important input for deciding ..." if compared to what, >> exactly? > Now before I try singing old wisdom from the neighbourhood of > The Mythical Man Month ... > How will a piece of source code, your own or someone else's, and > a language with tools fit these and the market as we might think > it is now? I find myself a bit confused on what you're talking about now -- exactly against what do you propose that I defend myself? Since Ray Blaak expressed past interest in OCaml I had the cheek to encourage him to really go and have a deeper look into OCaml when he finds time. That was it. I certainly miss, how all that here comes in: > project size, > project duration, > forced language, > availability of programmers (need to hire?), > job changes, > programmer skills, > multiple projects at the same time, > language switching e.g. between projects every other week, > time needed for education, > documentation needs, > future modification done by others, > future modification to be done by the author, > ... But let me give a real short answer to your request as it stands: > How will a piece of source code, your own or someone else's, and > a language with tools fit these and the market as we might think > it is now? It will depend on the ability of mine or someone else to code in this unnamed language with arbitrary tools. Note that I doubt that "we think" the same about the market and what counts -- finally -- is how the market is, not how we think about it, which might be a different thing altogether. Does that answer satisfy you? No? I thought so. You have to ask better questions then. > A rich set of opportunities for collecting some input, if only Questions as those rather wide ranging ones you just posed above are not "opportunities for collecting some input". They just stay questions. I fail to see the opportunity. Even if R.B. would use the suggested "stop watch" (and we all know how little the time alone will tell you), I hope you don't try to draw conclusion on all those topics: > project size, > project duration, > forced language, > availability of programmers (need to hire?), > job changes, > programmer skills, > multiple projects at the same time, > language switching e.g. between projects every other week, > time needed for education, > documentation needs, > future modification done by others, > future modification to be done by the author, > ... > in order to convince ourselves that some things might have changed > in software production (due to language changes?) while others Well, things have changed, but you're probably missing how. > haven't changed --for example we might get carried away by a Care not to use that all-inclusive sick-nurse style "we" here? If you get carried away: Your problem. If you insist I did, then say so. And note that I didn't give a specific factor of improvement of productivity. Brooks excludes "magical" improvements for large projects in orders of magnitude, not (a) for small projects (in large projects it's not the implementation that dominates) (b) not for reasonable factors. In small day-to-day development I don't think a factor of > subjective estimate of the usability of our preferred language. > In accord with the findings of Leon Festinger (1957). Good. That might be. How's than that C is rumoured to be so much less productive than Ada? Bah! George, you're not trying to find out things, but to win. At, I might say, every price. As I already said: Just ignore what I say and we'll be fine. I'm not conducting paid scientific research here on language usability and I've no interest in making converts. Just say that what I say cannot be proven, you refuse to believe anything of it and let it be done. _I_ do not see any way to help you here, esp. since above you just sketched a many man year research program as the things you need to get answered. How to you propose I answer to > How will a piece of source code, your own or someone else's, and > a language with tools fit these and the market as we might think > it is now? (...) Say "They fit well?". Would I be done then? Or would you call me deluded (not with that word of course) and we'd argue over what I say until I bring sworn affidavits? You know, I'm already convinced (though I doubt you exactly grasped of what), so I don't need to conduct any experiments or research in the directions _you_ require. You're not convinced and IMO unconvincable, but as I said: YMMV and I'll let you you're point of view and practice of programming. Since I don't work for or with you I don't have to find a common style with you. And for the rest: Well -- I just don't have the time. As I already said: I'm not even sure I know what you want. I reserve the right, though, to give some, perhaps not well recieved or well like answers to questions like "Why is Ada not more popular" or oppose some views on GC or type inference. Oppose, mind you. That means some statement of dissenting opinion and experience (which anybody can ignore at their will), but that doesn't mean I've to slug it out. That is what scientific studies are for and they usually take a bit more time than 30 minutes on usenet. I know a number of people who'd happily accept some research grants on these topics, so if you just happen to have some spare money and the need to answer > project size, > project duration, > forced language, > availability of programmers (need to hire?), > job changes, > programmer skills, > multiple projects at the same time, > language switching e.g. between projects every other week, > time needed for education, > documentation needs, > future modification done by others, > future modification to be done by the author, > ... is just so urgent and important to you, you might consider sponsoring them. Regards -- Markus