* Re: Programming language vote - results [not found] <343fbb5a.0@news.iprolink.ch> @ 1997-10-11 0:00 ` Gary L. Scott 1997-10-12 0:00 ` Jack Rudd ` (3 more replies) 1997-10-19 0:00 ` William Rapp 1 sibling, 4 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-11 0:00 UTC (permalink / raw) Oh the horror stories about Ada just about anyone in the defense industry could tell you...(inefficiency, bloat, development delays, budget overruns)...I dare you to fit a Jovial application that already max's out a computer's capabilities in the same box using OO techniques in Ada...In fact, multiply memory and CPU throughput by 10 and try it. You will likely be forced to back off OO quite a bit, making an even bigger mess of maintainability/reusability... Vincent Lambercy wrote: > After two weeks, Ada and Smalltalk seems to be the best languages. If > you > don't thik so (or if you think so), vote on > homepages.iprolink.ch/~lambercy -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott @ 1997-10-12 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott ` (3 more replies) 1997-10-13 0:00 ` David Ness ` (2 subsequent siblings) 3 siblings, 4 replies; 147+ messages in thread From: Jack Rudd @ 1997-10-12 0:00 UTC (permalink / raw) Gary L. Scott wrote: > > Oh the horror stories about Ada just about anyone in the defense > industry could tell you...(inefficiency, bloat, development delays, > budget overruns)...I dare you to fit a Jovial application that already > max's out a computer's capabilities in the same box using OO techniques > in Ada...In fact, multiply memory and CPU throughput by 10 and try it. > You will likely be forced to back off OO quite a bit, making an even > bigger mess of maintainability/reusability... > > Vincent Lambercy wrote: > > > After two weeks, Ada and Smalltalk seems to be the best languages. ... Problems along the above lines helped get a very large defense project cancelled that was near and dear to me. I may never forgive the folks who pushed OO in Ada on that project. Incidentally, the Air Force has now backed off from its previous position of requiring Ada on all new software projects. Jack Rudd Lockheed Martin Federal Systems Boulder, CO ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-12 0:00 ` Jack Rudd @ 1997-10-13 0:00 ` Gary L. Scott 1997-10-13 0:00 ` safetran ` (2 subsequent siblings) 3 siblings, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-13 0:00 UTC (permalink / raw) Jack Rudd wrote: > Gary L. Scott wrote: > > > > Oh the horror stories about Ada just about anyone in the defense > > industry could tell you...(inefficiency, bloat, development delays, > > budget overruns)...I dare you to fit a Jovial application that > already > > max's out a computer's capabilities in the same box using OO > techniques > > in Ada...In fact, multiply memory and CPU throughput by 10 and try > it. > > You will likely be forced to back off OO quite a bit, making an even > > > bigger mess of maintainability/reusability... > > > > Vincent Lambercy wrote: > > > > > After two weeks, Ada and Smalltalk seems to be the best languages. > > ... > Problems along the above lines helped get a very large defense > project cancelled that was near and dear to me. I may never > forgive the folks who pushed OO in Ada on that project. > > Incidentally, the Air Force has now backed off from its previous > position of requiring Ada on all new software projects. I am aware of 3 projects that fairly recently were required to use Ada by the Air Force. I don't think that they speak with one voice on this subject. > > > Jack Rudd > Lockheed Martin Federal Systems > Boulder, CO > -- Gary L. Scott Lockheed Martin Tactical Aircraft Systems scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-12 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott @ 1997-10-13 0:00 ` safetran 1997-10-13 0:00 ` FRS DES 1997-10-13 0:00 ` Jack Rudd 1997-10-13 0:00 ` Robert Munck [not found] ` <3442B745.5352@lmco.com> 3 siblings, 2 replies; 147+ messages in thread From: safetran @ 1997-10-13 0:00 UTC (permalink / raw) Jack Rudd wrote: > > Gary L. Scott wrote: > > > > Oh the horror stories about Ada just about anyone in the defense > > industry could tell you...(inefficiency, bloat, development delays, >> (Deleted text)... > > > > Vincent Lambercy wrote: > > > > > After two weeks, Ada and Smalltalk seems to be the best languages. > ... > Problems along the above lines helped get a very large defense > project cancelled that was near and dear to me. I may never > forgive the folks who pushed OO in Ada on that project. > > Incidentally, the Air Force has now backed off from its previous > position of requiring Ada on all new software projects. > > Jack Rudd > Lockheed Martin Federal Systems > Boulder, CO Can you provide more info about why the project got cancelled ? I have been using Ada quite successfully since about 1991 - non defense/non aerospace companies. The projects are _hard_ real-time, embedded (we design our own embedded hardware) and safety critical. In fact being safety critical, the software _has_ to meet its deadlines otherwise there could be some serious problems :) The compilers (2 different manufacturers) I have used have generated assembly that was very efficient and there was not much code bloat. Admittedly the projects were based on 68332's or 68030 (not exactly 8051's) and we had about 512KB of ROM space with 256KB RAM. 1 project we used Yourdon/Ward-Mellor Real-time extensions as the methodology. The other 2 projects were done using Shlaer-Mellor OOA. -- Rakesh ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` safetran @ 1997-10-13 0:00 ` FRS DES 1997-10-13 0:00 ` Jack Rudd 1 sibling, 0 replies; 147+ messages in thread From: FRS DES @ 1997-10-13 0:00 UTC (permalink / raw) In article <34424524.B8C67C@kaiwan.com>, safetran <safetran@kaiwan.com> writes: >Can you provide more info about why the project got cancelled ? > >I have been using Ada quite successfully since about 1991 - non >defense/non aerospace companies. The projects are _hard_ real-time, >embedded (we design our own embedded hardware) and safety critical. In >fact being safety critical, the software _has_ to meet its deadlines >otherwise there could be some serious problems :) > > This thread has really ceased to have any relation to APL or J. Could you please take it to some other group? Thank you. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` safetran 1997-10-13 0:00 ` FRS DES @ 1997-10-13 0:00 ` Jack Rudd 1997-10-14 0:00 ` Philip Brashear 1 sibling, 1 reply; 147+ messages in thread From: Jack Rudd @ 1997-10-13 0:00 UTC (permalink / raw) safetran wrote: > > Can you provide more info about why the project got cancelled ? The short answer is, inability to meet cost and schedule constraints. One large contributing factor to this was the use of OO in Ada by a team that had no previous experience with OO in Ada. The other contributing factors are irrelevant to this thread. > I have been using Ada quite successfully since about 1991 - non > defense/non aerospace companies. The projects are _hard_ real-time, > embedded (we design our own embedded hardware) and safety critical. In > fact being safety critical, the software _has_ to meet its deadlines > otherwise there could be some serious problems :) > Fine. I have no quarrel with success. How did your team perform the first time using OO in Ada? Was it on a small project? Jack Rudd ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` Jack Rudd @ 1997-10-14 0:00 ` Philip Brashear 1997-10-14 0:00 ` Gary L. Scott 0 siblings, 1 reply; 147+ messages in thread From: Philip Brashear @ 1997-10-14 0:00 UTC (permalink / raw) In article <34428215.41C6@lmco.com>, Jack Rudd <jack.rudd@lmco.com> wrote: >safetran wrote: >> >> Can you provide more info about why the project got cancelled ? > >The short answer is, inability to meet cost and schedule constraints. >One large contributing factor to this was the use of OO in Ada by >a team that had no previous experience with OO in Ada. The other >contributing factors are irrelevant to this thread. > >> I have been using Ada quite successfully since about 1991 - non >> defense/non aerospace companies. The projects are _hard_ real-time, >> embedded (we design our own embedded hardware) and safety critical. In >> fact being safety critical, the software _has_ to meet its deadlines >> otherwise there could be some serious problems :) >> >Fine. I have no quarrel with success. How did your team perform the >first time using OO in Ada? Was it on a small project? > >Jack Rudd And there you have it. Projects that use Ada (or C or COBOL or ...) appropriately succeed. Projects that use Ada as if it were C or Ada as if it were COBOL or C as if it were COBOL or ... don't. Blame the management, blame the designers, blame the programmers ... But why blame the language? If the shoe doesn't fit (or if you don't know how to lace it), don't wear it! Phil ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-14 0:00 ` Philip Brashear @ 1997-10-14 0:00 ` Gary L. Scott 0 siblings, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-14 0:00 UTC (permalink / raw) Philip Brashear wrote: > In article <34428215.41C6@lmco.com>, Jack Rudd <jack.rudd@lmco.com> > wrote: > >safetran wrote: > >> > >> Can you provide more info about why the project got cancelled ? > > > >The short answer is, inability to meet cost and schedule constraints. > > >One large contributing factor to this was the use of OO in Ada by > >a team that had no previous experience with OO in Ada. The other > >contributing factors are irrelevant to this thread. > > > >> I have been using Ada quite successfully since about 1991 - non > >> defense/non aerospace companies. The projects are _hard_ > real-time, > >> embedded (we design our own embedded hardware) and safety > critical. In > >> fact being safety critical, the software _has_ to meet its > deadlines > >> otherwise there could be some serious problems :) > >> > >Fine. I have no quarrel with success. How did your team perform the > > >first time using OO in Ada? Was it on a small project? > > > >Jack Rudd > > And there you have it. Projects that use Ada (or C or COBOL or ...) > appropriately succeed. Projects that use Ada as if it were C or Ada > as if > it were COBOL or C as if it were COBOL or ... don't. > > Blame the management, blame the designers, blame the programmers ... > But why blame the language? > > If the shoe doesn't fit (or if you don't know how to lace it), don't > wear it! > > Phil In my original post, it was my intent to blame the inappropriate use of OO at the insistence of management caught up in the OO fad. We were writing an entire operating system and all of its "applications", attempting to be OO "pure". Ada is a fine language, used appropriately... -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-12 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott 1997-10-13 0:00 ` safetran @ 1997-10-13 0:00 ` Robert Munck 1997-10-13 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott [not found] ` <3442B745.5352@lmco.com> 3 siblings, 2 replies; 147+ messages in thread From: Robert Munck @ 1997-10-13 0:00 UTC (permalink / raw) On Sun, 12 Oct 1997 23:41:42 -0600, Jack Rudd <jack.rudd@lmco.com> wrote: >Gary L. Scott wrote: >> >> Oh the horror stories about Ada just about anyone in the defense >> industry could tell you...(inefficiency, bloat, development delays, >> budget overruns)... >... >Problems along the above lines helped get a very large defense >project cancelled that was near and dear to me. I may never >forgive the folks who pushed OO in Ada on that project. Ada turned out to be an excellent scapegoat for the many management failures that are found in software projects in general and large projects done by large contractors for the DoD in particular. It will be interesting to see what gets the blame now that "you don't have Ada to kick around anymore." I'll bet that it's Microsoft and/or Sun. Bob Munck Mill Creek Systems LC ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` Robert Munck @ 1997-10-13 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott 1 sibling, 0 replies; 147+ messages in thread From: Jack Rudd @ 1997-10-13 0:00 UTC (permalink / raw) Robert Munck wrote: > > Ada turned out to be an excellent scapegoat for the many > management failures that are found in software projects in > general and large projects done by large contractors for the > DoD in particular. Now remember, I didn't blame "Ada" per se. If the team hadn't tried to do OO in Ada, the situation would have been more manageable. Not to say that there weren't other problems too; but these newsgroups are focused on language-related issues. And the team had significant problems with OO in Ada. That's simply a fact. >It will be interesting to see what gets > the blame now that "you don't have Ada to kick around anymore." > I'll bet that it's Microsoft and/or Sun. > Where did you get the idea that we don't have Ada to kick around any more? Ada is still required on some projects. Jack Rudd ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` Robert Munck 1997-10-13 0:00 ` Jack Rudd @ 1997-10-13 0:00 ` Gary L. Scott 1 sibling, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-13 0:00 UTC (permalink / raw) Robert Munck wrote: > On Sun, 12 Oct 1997 23:41:42 -0600, Jack Rudd <jack.rudd@lmco.com> > wrote: > > >Gary L. Scott wrote: > >> > >> Oh the horror stories about Ada just about anyone in the defense > >> industry could tell you...(inefficiency, bloat, development delays, > > >> budget overruns)... > >... > >Problems along the above lines helped get a very large defense > >project cancelled that was near and dear to me. I may never > >forgive the folks who pushed OO in Ada on that project. > > Ada turned out to be an excellent scapegoat for the many > management failures that are found in software projects in > general and large projects done by large contractors for the > DoD in particular. It will be interesting to see what gets > the blame now that "you don't have Ada to kick around anymore." > I'll bet that it's Microsoft and/or Sun. > > Bob Munck > Mill Creek Systems LC I agree completely that there were many short-sighted decisions being made by both management and our customers. However, I don't understand the "don't have Ada..." comment. We are still using and still being directed to use Ada by our customers on "new" projects. Very few of us are against Ada or "OO" or the attempts to solve the "language proliferation, maintenance/reusability" issues. I am against not being allowed to make the decision as to which language best solves the problem that I have to solve and being dictated to meet cost and schedules based upon historical data that involved using a different programming language, especially when I have little or no experience in the new language. Let me decide where I can implement an "OO" design and where I can't rather than making arbitrary/blanket requirements for "pure OO" development. Let me develop the skills on a small project first. Doesn't that make more sense? -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <3442B745.5352@lmco.com>]
* Re: Programming language vote - results [not found] ` <3442B745.5352@lmco.com> @ 1997-10-15 0:00 ` Gary L. Scott 1997-10-16 0:00 ` James Giles 1 sibling, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-15 0:00 UTC (permalink / raw) William Dale Jr wrote: > Jack Rudd wrote: > > > > Gary L. Scott wrote: > > > > > > Oh the horror stories about Ada just about anyone in the defense > > > industry could tell you...(inefficiency, bloat, development > delays, > > > budget overruns)...I dare you to fit a Jovial application that > already > > > max's out a computer's capabilities in the same box using OO > techniques > > > in Ada...In fact, multiply memory and CPU throughput by 10 and try > it. > > > You will likely be forced to back off OO quite a bit, making an > even > > > bigger mess of maintainability/reusability... > > > > > If you consider that most programmers on defense programs get no > training on Ada, much less OO and real-time issues, it is surprizing > that so many projects ARE SUCCESSFUL. The advantages of Ada are not > FREE. Additional memory, and processor horsepower may/will be needed. > > If these cannot be tolorated and management ignores the risk - well, > the > above is what you get. I was intending to comment on the miss-application of OO techniques rather than the use of Ada specifically. There was considerable training provided in Ada, OOA, OOD, etc. The problem was one of using the wrong tool for the specific task at the direction of management (largely). > > > Ignorance of the domain and the forced use of obscure (MIL-STD-1750A) > processors have also given Ada a bad name. It is a poor workman who > blames his tools. ( Then again, the boss didn't give you any tools, > did > he? ) MIL-STD-1750A processors may be obscure, but they are widely used on military aircraft. If a Pentium or a Power-PC could survive the environmental conditions that 1750 processors are required to survive in, we'd love to use them. As for tools, cost for tools was no object; workstations, configuration management tools, significant training in OOA, OOD, OOP, you name it. But we were still producing operating system code and applications for an underpowered processor with too little memory. > > > > > Vincent Lambercy wrote: > > > > > > > After two weeks, Ada and Smalltalk seems to be the best > languages. > > ... > > Problems along the above lines helped get a very large defense > > project cancelled that was near and dear to me. I may never > > forgive the folks who pushed OO in Ada on that project. > > > Again, I bet you had no training in OO with Ada nor got any OO design > tools and expected all the great Ada "'illities" to be for FREE. > > > Incidentally, the Air Force has now backed off from its previous > > position of requiring Ada on all new software projects. > > > > This, I believe, is a good thing. Backed off, but not eliminated. We still seem to be required to use Ada on all "new" development (usually a costly waste of time due to the age/near obsolescence of some of these devices). If we replace an obsolete CPU and nothing else, the code gets redesigned in Ada. It seems to be written in to some "long-term" contracts. > > > > Jack Rudd > > Lockheed Martin Federal Systems > > Boulder, CO > > -- > ================================================= > William L. Dale mailto:william.dale.jr@lmco.com > ~~~~ Round up the usual disclaimers ~~~~ > ================================================= > "You can have one of two beliefs about miracles : > 1. There are no such thing as miracles. > 2. Everything is a miracle. > . . . I prefer the later." A.E. > ------------------------------------------------- -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results [not found] ` <3442B745.5352@lmco.com> 1997-10-15 0:00 ` Gary L. Scott @ 1997-10-16 0:00 ` James Giles 1997-10-16 0:00 ` Andrew Haley 1 sibling, 1 reply; 147+ messages in thread From: James Giles @ 1997-10-16 0:00 UTC (permalink / raw) William Dale Jr <William.Dale.Jr@lmco.com> wrote in article <3442B745.5352@lmco.com>... [...] > Ignorance of the domain and the forced use of obscure (MIL-STD-1750A) > processors have also given Ada a bad name. It is a poor workman who > blames his tools. ( Then again, the boss didn't give you any tools, did > he? ) The line "It's a poor workman that blames his tools" is one of my favorites on the net. It is usually used to defend particularly badly designed tools (though, I do not accuse you in this instance). The correct response is: "A good workman acquires the best tools and discards those which don't suit his purposes." -- J. Giles Ricercar Software ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` James Giles @ 1997-10-16 0:00 ` Andrew Haley 0 siblings, 0 replies; 147+ messages in thread From: Andrew Haley @ 1997-10-16 0:00 UTC (permalink / raw) William Dale Jr <William.Dale.Jr@lmco.com> wrote in article <3442B745.5352@lmco.com>... [...] > Ignorance of the domain and the forced use of obscure (MIL-STD-1750A) > processors have also given Ada a bad name. I did a Forth for MIL-STD-1750A: it's a nice architecture, and was a pleasure to program. I don't see how it's possible to blame that processor for any problems with Ada. Andrew. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott 1997-10-12 0:00 ` Jack Rudd @ 1997-10-13 0:00 ` David Ness 1997-10-14 0:00 ` Randy MacDonald 1997-10-14 0:00 ` Jan Karman 1997-10-13 0:00 ` Matthew Heaney 1997-10-13 0:00 ` Robert S. White 3 siblings, 2 replies; 147+ messages in thread From: David Ness @ 1997-10-13 0:00 UTC (permalink / raw) How about dropping comp.lang.apl from this thread? It doesn't seem to have much to do with APL/J... Gary L. Scott wrote: > ><SNIP of lots of stuff about ADA> > > -- > Gary L. Scott > scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` David Ness @ 1997-10-14 0:00 ` Randy MacDonald 1997-10-14 0:00 ` Jan Karman 1 sibling, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-14 0:00 UTC (permalink / raw) In article <34428914.2D71D0F@ibm.net>, dness@ibm.net wrote: >How about dropping comp.lang.apl from this thread? It doesn't seem >to have much to do with APL/J... Note that APL is #4 on the list. Your vote seems to _really_ count, so don't delay, act today. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` David Ness 1997-10-14 0:00 ` Randy MacDonald @ 1997-10-14 0:00 ` Jan Karman 1997-10-15 0:00 ` Alan E & Carmel J Brain 1 sibling, 1 reply; 147+ messages in thread From: Jan Karman @ 1997-10-14 0:00 UTC (permalink / raw) David Ness <dness@ibm.net> wrote in article <34428914.2D71D0F@ibm.net>... > How about dropping comp.lang.apl from this thread? It doesn't seem > to have much to do with APL/J... > > Gary L. Scott wrote: > > > ><SNIP of lots of stuff about ADA> > > In general I find it interesting reading other people's opinion on related subjects. If somebody likes to compare computer languages by way of a poll then APL is involved and related comments fit quite well in the news group. If it wouldn't then we would have APL and the rest of the world. I repeatingly see people try to preserve other people from doing things which are really harmless and not disturbing. Is this the "religious thread" some people talk about? I have in my news-setup 10 days for keeping messages. In cla the headers always fit on one page. And I feel no in the least obliged to read them all. In fact I have set "Mark as read after leaving a newsgroup" in my setup. BTW, the previous poster may learn in this specific case (ADA vs APL) a closer relation from Jack Rudd's contribution to APL93 (Toronto) ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-14 0:00 ` Jan Karman @ 1997-10-15 0:00 ` Alan E & Carmel J Brain 1997-10-15 0:00 ` D'Arcy J.M. Cain 1997-10-17 0:00 ` Robert I. Eachus 0 siblings, 2 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-15 0:00 UTC (permalink / raw) Jan Karman wrote: > > David Ness <dness@ibm.net> wrote in article <34428914.2D71D0F@ibm.net>... > > How about dropping comp.lang.apl from this thread? It doesn't seem > > to have much to do with APL/J... > > > > Gary L. Scott wrote: > > > > > ><SNIP of lots of stuff about ADA> > > > > > In general I find it interesting reading other people's opinion on related > subjects. > If somebody likes to compare computer languages by way of a poll then APL > is involved and related comments fit quite well in the news group. If it > wouldn't then we would have APL and the rest of the world. > I repeatingly see people try to preserve other people from doing things > which are really harmless and not disturbing. Is this the "religious > thread" some people talk about? I guess I'm probably the only contributor here whose preferred language is Ada-95, and who has used a lot of APL in the commercial environment. Would you believe an integrated accounting, invoicing and GUI-aided Cost estimation system with multiple workstations and a file server in 1982? Yes 1982. MCM-824 workstations. Every time someone says how terse and powerful C is, I think of APL. But for programs that have to be maintained, and have to be reliable, give me Ada, -83 or -95. For reasons why, see http://www.adahome.com -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` Alan E & Carmel J Brain @ 1997-10-15 0:00 ` D'Arcy J.M. Cain 1997-10-15 0:00 ` FRS DES ` (4 more replies) 1997-10-17 0:00 ` Robert I. Eachus 1 sibling, 5 replies; 147+ messages in thread From: D'Arcy J.M. Cain @ 1997-10-15 0:00 UTC (permalink / raw) Alan E & Carmel J Brain wrote: > Every time someone says how terse and powerful C is, I think of APL. My favourite quote about APL - "I refuse to use any computer language in which the proponents shove snippets of code under each other's nose saying 'I bet you can't guess what this does!'" -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` D'Arcy J.M. Cain @ 1997-10-15 0:00 ` FRS DES 1997-10-15 0:00 ` Mark Stephen ` (3 subsequent siblings) 4 siblings, 0 replies; 147+ messages in thread From: FRS DES @ 1997-10-15 0:00 UTC (permalink / raw) In article <3444BFC6.794BDF32@druid.net>, "D'Arcy J.M. Cain" <darcy@druid.net> writes: >Subject: Re: Programming language vote - results >From: "D'Arcy J.M. Cain" <darcy@druid.net> >Date:Wed, 15 Oct 1997 09:06:14 -0400 > >Alan E & Carmel J Brain wrote: >> Every time someone says how terse and powerful C is, I think of APL. > >My favourite quote about APL - "I refuse to use any computer language >in which the proponents shove snippets of code under each other's >nose saying 'I bet you can't guess what this does!'" > > I have been a full-time professional APL programmer for more than 7 years. I am active in the local and national User groups. I have NEVER seen someone doing this. I will g\rant that it has occasionally happened between college students recently exposed to APL, but one expects sophomoric behaviour from sophomores. In any case, there is a nationaly publicized "obfuscated C contest" where the contestants spend great time and effort constructing deliberately obsucre and mangled but functional programs. By the above reasoning, you should never use C either. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` D'Arcy J.M. Cain 1997-10-15 0:00 ` FRS DES @ 1997-10-15 0:00 ` Mark Stephen 1997-10-17 0:00 ` Randy MacDonald 1997-10-16 0:00 ` Alan E & Carmel J Brain ` (2 subsequent siblings) 4 siblings, 1 reply; 147+ messages in thread From: Mark Stephen @ 1997-10-15 0:00 UTC (permalink / raw) In article <3444BFC6.794BDF32@druid.net>, "D'Arcy J.M. Cain" <darcy@druid.net> wrote: >Alan E & Carmel J Brain wrote: >> Every time someone says how terse and powerful C is, I think of APL. > >My favourite quote about APL - "I refuse to use any computer language >in which the proponents shove snippets of code under each other's >nose saying 'I bet you can't guess what this does!'" > Damn! Where's my copy of "Devil's DP Dictionary"? From memory There are three things a man must do before his life is done. Write two lines of APL and make the buggers run. best wishes, mark s. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` Mark Stephen @ 1997-10-17 0:00 ` Randy MacDonald 0 siblings, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-17 0:00 UTC (permalink / raw) In article <dWVR08LNqpWb092yn@enter.net>, mstephen@enter.net (Mark Stephen) wrote: > There are three things a man must do > before his life is done. > Write two lines of APL > and make the buggers run. With apologies to Crocodile Dundee... That's not a life... -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` D'Arcy J.M. Cain 1997-10-15 0:00 ` FRS DES 1997-10-15 0:00 ` Mark Stephen @ 1997-10-16 0:00 ` Alan E & Carmel J Brain 1997-10-16 0:00 ` FRS DES ` (2 more replies) 1997-10-16 0:00 ` Randy MacDonald [not found] ` <01bcdad2$fa9fdf60$25a43a91@basil.omroep.nl> 4 siblings, 3 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-16 0:00 UTC (permalink / raw) D'Arcy J.M. Cain wrote: > > Alan E & Carmel J Brain wrote: > > Every time someone says how terse and powerful C is, I think of APL. > > My favourite quote about APL - "I refuse to use any computer language > in which the proponents shove snippets of code under each other's > nose saying 'I bet you can't guess what this does!'" Trouble is, this is true. I wrote a security system that took a user input, used it to write a program which when executed wrote another program that modified the first program, exited, and the first program then gave access to certain data. In 2 lines. Due to hardware limitations, this 2-liner was impossible to make "hidden" so I made it Cryptic, and self-modifying. 2 months later, even I couldn't figure out exactly what it did. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` Alan E & Carmel J Brain @ 1997-10-16 0:00 ` FRS DES 1997-10-17 0:00 ` Jerry van Dijk 1997-10-16 0:00 ` John Sullivan 1997-10-17 0:00 ` Randy MacDonald 2 siblings, 1 reply; 147+ messages in thread From: FRS DES @ 1997-10-16 0:00 UTC (permalink / raw) In article <34466EB4.3381@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: >D'Arcy J.M. Cain wrote: >> >> Alan E & Carmel J Brain wrote: >> > Every time someone says how terse and powerful C is, I think of APL. >> >> My favourite quote about APL - "I refuse to use any computer language >> in which the proponents shove snippets of code under each other's >> nose saying 'I bet you can't guess what this does!'" > >Trouble is, this is true. I wrote a security system that took a user >input, used it to write a program which when executed wrote another >program that modified the first program, exited, and the first program >then gave access to certain data. In 2 lines. Due to hardware >limitations, this 2-liner was impossible to make "hidden" so I made it >Cryptic, and self-modifying. 2 months later, even I couldn't figure out >exactly what it did. > Of course, you were deliberately *trying* to be cryptic, as a security measure (not the best way to do security, IMO, but that is another matter). I would say that your code fulfilled its designed function pretty well. It might have been a good idea to document what it did, how and why, and sve this in a secure (off-line) place, since the code was intentionally obscure. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` FRS DES @ 1997-10-17 0:00 ` Jerry van Dijk 0 siblings, 0 replies; 147+ messages in thread From: Jerry van Dijk @ 1997-10-17 0:00 UTC (permalink / raw) In article <19971016134401.JAA11348@ladder01.news.aol.com> frsdes@aol.com writes: >Of course, you were deliberately *trying* to be cryptic, as a security >measure (not the best way to do security, IMO, but that is another matter). In our company this is known as the SBO method. SBO = Security By Obscurity :-) -- -- Jerry van Dijk | Leiden, Holland -- Consultant | Team Ada -- Ordina Finance | jdijk@acm.org ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` Alan E & Carmel J Brain 1997-10-16 0:00 ` FRS DES @ 1997-10-16 0:00 ` John Sullivan 1997-10-17 0:00 ` Randy MacDonald 1997-10-17 0:00 ` Alan E & Carmel J Brain 1997-10-17 0:00 ` Randy MacDonald 2 siblings, 2 replies; 147+ messages in thread From: John Sullivan @ 1997-10-16 0:00 UTC (permalink / raw) In article <34466EB4.3381@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes >D'Arcy J.M. Cain wrote: >> >> Alan E & Carmel J Brain wrote: >> > Every time someone says how terse and powerful C is, I think of APL. >> >> My favourite quote about APL - "I refuse to use any computer language >> in which the proponents shove snippets of code under each other's >> nose saying 'I bet you can't guess what this does!'" > >Trouble is, this is true. I wrote a security system that took a user >input, used it to write a program which when executed wrote another >program that modified the first program, exited, and the first program >then gave access to certain data. In 2 lines. Due to hardware >limitations, this 2-liner was impossible to make "hidden" so I made it >Cryptic, and self-modifying. 2 months later, even I couldn't figure out >exactly what it did. > You can do exactly the same thing in most other languages. I could write a book about the Fortran I've had to debug that was impenetrable. Stuff from reputable suppliers that came undebugged, with so many computed goto's that the diagrams I drew to try to see what was going on resembled spaghetti. So, why didn't you document your code when you wrote it? Don't blame APL for your own inadequacies. John Sullivan ------------- remove the dots from the first three (Welsh) words for my real address ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` John Sullivan @ 1997-10-17 0:00 ` Randy MacDonald 1997-10-17 0:00 ` Alan E & Carmel J Brain 1 sibling, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-17 0:00 UTC (permalink / raw) In article <3gIvKGAfUmR0EwEl@yddraiggoch.demon.co.uk>, John Sullivan <john@y.ddraig.goch.demon.co.uk> wrote: >You can do exactly the same thing in most other languages. but it takes sooo much longer.... >So, why didn't you document your code when you wrote it? Don't blame APL >for your own inadequacies. I'm not sure if the impenetrability of the "security" code was a problem or a solution, are you? The lovely thing about incomprehensible APL is, when you find it, how little of it there is, compared to reams of C. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` John Sullivan 1997-10-17 0:00 ` Randy MacDonald @ 1997-10-17 0:00 ` Alan E & Carmel J Brain 1997-10-17 0:00 ` John Sullivan 1 sibling, 1 reply; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-17 0:00 UTC (permalink / raw) John Sullivan wrote: > In 2 lines. Due to hardware > >limitations, this 2-liner was impossible to make "hidden" so I made it > >Cryptic, and self-modifying. 2 months later, even I couldn't figure out > >exactly what it did. > > > You can do exactly the same thing in most other languages. Disagree. Truly impenetrable FORTRAN can't be written in only 2 lines. I repeat 2 lines. Not 2 pages. 2 lines. For a real rat's nest of FORTRAN, you need more than 2 pages. > So, why didn't you document your code when you wrote it? Don't blame APL > for your own inadequacies. *SIGH* Obviously I didn't make myself clear. 1. I had to write a security system. 2. I couldn't stop any hacker from being able to read the source code. (It was interpreted). 3. So I deliberately tried to made it obscure, so no casual hacker could break in in a few minutes. 4. I succeeded in my attempt. If the above isn't clear to you, I'll explain in more detail via e-mail. Yes, the code was documented, giving the exact algorithms used, and said documentation (about 12 pages) was kept in a safe. The point was that even I, the author of the code, could not look at a mere 2 lines and figure out what the thing did, just from looking at the source. Regarding inadequacies, I can't exactly blame APL for mine, there are too many! An inability to suffer fools gladly being one of them. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-17 0:00 ` Alan E & Carmel J Brain @ 1997-10-17 0:00 ` John Sullivan 0 siblings, 0 replies; 147+ messages in thread From: John Sullivan @ 1997-10-17 0:00 UTC (permalink / raw) In article <34481248.4F0A@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes >John Sullivan wrote: >> In 2 lines. Due to hardware >> >limitations, this 2-liner was impossible to make "hidden" so I made it >> >Cryptic, and self-modifying. 2 months later, even I couldn't figure out >> >exactly what it did. >> > >> You can do exactly the same thing in most other languages. > >Disagree. Truly impenetrable FORTRAN can't be written in only 2 lines. I >repeat 2 lines. Not 2 pages. 2 lines. >For a real rat's nest of FORTRAN, you need more than 2 pages. What's all this crap about only two lines? Are you trying to claim somne sort of prize -- "Look over here guys, I got this program down to just 2 lines. Bet you can't figure out what it does"! > >> So, why didn't you document your code when you wrote it? Don't blame APL >> for your own inadequacies. > >*SIGH* Obviously I didn't make myself clear. No, you made yourself only too clear. > >1. I had to write a security system. >2. I couldn't stop any hacker from being able to read the source code. >(It was interpreted). >3. So I deliberately tried to made it obscure, so no casual hacker could >break in in a few minutes. >4. I succeeded in my attempt. That's obvious. You succeeded in preventing yourself knowing what your own "program" was doing. Very secure system, that. > >If the above isn't clear to you, I'll explain in more detail via e-mail. Don't bother. I really couldn't care one way or the other. I am fed up with hearing about people using unsuitable languages for the jobs they have to do. This is just another boring example. Why you want to boast about it beats me. Lesson 1: Do not use an interpreted language to write a security system. > >Yes, the code was documented, giving the exact algorithms used, and said >documentation (about 12 pages) was kept in a safe. The point was that >even I, the author of the code, could not look at a mere 2 lines and >figure out what the thing did, just from looking at the source. Maybe you should read some textbooks on program design, the sort of things I, and no doubt many other APLers also, was encouraged to read, in order to learn how to program so you cannot get into the situation you describe. And I repeat, using different words this time, your attempted solution to your problem was totally inadequate. Do not blame APL for this inadequacy. > >Regarding inadequacies, I can't exactly blame APL for mine, there are >too many! An inability to suffer fools gladly being one of them. You muat be very insufferable then. And try not to look in the mirror. John Sullivan ------------- remove the dots from the first three (Welsh) words for my real address ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-16 0:00 ` Alan E & Carmel J Brain 1997-10-16 0:00 ` FRS DES 1997-10-16 0:00 ` John Sullivan @ 1997-10-17 0:00 ` Randy MacDonald 1997-10-20 0:00 ` Alan E & Carmel J Brain 2 siblings, 1 reply; 147+ messages in thread From: Randy MacDonald @ 1997-10-17 0:00 UTC (permalink / raw) In article <34466EB4.3381@dynamite.com.au>, aebrain@dynamite.com.au wrote: >..ines. Due to hardware >limitations, this 2-liner was impossible to make "hidden" so I made it >Cryptic, and self-modifying. 2 months later, even I couldn't figure out >exactly what it did. So, where's the code? Sounds like a challenge. If it's MCM code, you might be interested in knowing we are still using code derived from that system ([]XR []XW ring a bell?) -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-17 0:00 ` Randy MacDonald @ 1997-10-20 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` FRS DES ` (4 more replies) 0 siblings, 5 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-20 0:00 UTC (permalink / raw) Randy MacDonald wrote: > > In article <34466EB4.3381@dynamite.com.au>, aebrain@dynamite.com.au wrote: > >..ines. Due to hardware > >limitations, this 2-liner was impossible to make "hidden" so I made it > >Cryptic, and self-modifying. 2 months later, even I couldn't figure out > >exactly what it did. > > So, where's the code? Sounds like a challenge. No. Please. I'm begging. I've spent the better part of my professional life trying to get rid of the "fastest gun in the west" mentality of programming. "There are two ways to write a program: Either make it so complex, there's nothing obviously wrong, or so simple that there's obviously nothing wrong." Hence my preference for Ada. When listening to C weenies - er - enthusiasts talking about how their code is so tight, so efficient, and above all so impenetrable that it's obviously superior to another solution (in Ada so clear that "Any Fool could have written that"), I have to take a dried-frog pill and count to 10. In my younger and more foolish days, I was of a like mind. Now I think that APL has a place, but only in small, one-use throw-aways, and where terseness if vital (as in downloading complex programs over low-bandwidth data links). Probably other, similar areas as well. I'm glad it exists, as I'd hate to have to invent it! I once made the mistake of lending one of these C Hackers my old copy of "Structured Programming in APL" (a title that still leaves me gasping at the Oxymoron), and he's now a confirmed APL enthusiast. > If it's MCM code, you > might be interested in knowing we are still using code derived from that > system ([]XR []XW ring a bell?) Yes. All too well. ACKH. (Imagine Bill the Cat, that's my reaction) Oh, and of course Quad ZZ. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Alan E & Carmel J Brain @ 1997-10-20 0:00 ` FRS DES 1997-10-21 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` Lawrence Kirby ` (3 subsequent siblings) 4 siblings, 1 reply; 147+ messages in thread From: FRS DES @ 1997-10-20 0:00 UTC (permalink / raw) In article <344BCED0.2D51@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: > Now I think that APL has a place, >but only in small, one-use throw-aways, and where terseness if vital (as >in downloading complex programs over low-bandwidth data links). Probably >other, similar areas as well. I'm glad it exists, as I'd hate to have to >invent it! Those of us who spend our full time working on multi-megabyte APL programs, sold to Fortune 500 companies, written entirely in APL, disagree with your notion of its "Place". I woulf be the first toi agree that not every task is best accomplished in APL (or any other single language), but it is an excellant tool in a *wide* range of situations. Properly written and commented, it need be no more obscure than any other programming language. I grant that it is possible to write particularly obscure APL, but have you looked at the output of the "obfuscated C contest" lately. Idiocy canb be committed in any language. > >I once made the mistake of lending one of these C Hackers my old copy of >"Structured Programming in APL" (a title that still leaves me gasping at >the Oxymoron), and he's now a confirmed APL enthusiast. > APL does not *enforce* structured programming (neither does C), but structured programming is perfectly possible (and not uncommen) in APL. Modern APL supports such control structures as IF/ElseIF/Else/Endif; For/EndFor/ Select/Case/Case/EndSelect; Repeat/Until; and Do While/EndDo which can aid the programmer in creating clear code, and can often improve run-time speed as well. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` FRS DES @ 1997-10-21 0:00 ` Alan E & Carmel J Brain 0 siblings, 0 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-21 0:00 UTC (permalink / raw) FRS DES wrote: > > In article <344BCED0.2D51@dynamite.com.au>, Alan E & Carmel J Brain > <aebrain@dynamite.com.au> writes: > > > Now I think that APL has a place, > >but only in small, one-use throw-aways, and where terseness if vital (as > >in downloading complex programs over low-bandwidth data links). Probably > >other, similar areas as well. I'm glad it exists, as I'd hate to have to > >invent it! > > Those of us who spend our full time working on multi-megabyte APL > programs, sold to Fortune 500 companies, written entirely in APL, disagree > with your notion of its "Place". Why is it in APL? Because at the time the first version was written, that was the most appropriate choice of language available, and because no single upgrade was worth a re-write from the ground up? If the code was to be written from the start NOW with the tools now available, would APL be the best choice? I will willingly admit that in some cases at least, the answer to that last may well be YES. But I'd be interested in knowing why. I'm not being facetious or sarcastic, I genuinely want to exploit another professional's expertise (for free) I admit the idea of multi-megabyte APL rather boggles my mind. The configuration management alone must be an interesting challenge on such a large project. > I woulf be the first toi agree that not > every task is best accomplished in APL (or any other single language), but > it is an excellant tool in a *wide* range of situations. Properly written > and commented, it need be no more obscure than any other programming > language. I grant that it is possible to write particularly obscure APL, > but have you looked at the output of the "obfuscated C contest" lately. > Idiocy canb be committed in any language. Concur. It can be done in Ada too, it just requires a higher order of idiocy. I guess that's the nub: that good APL requires a really good (ie gifted) programmer, whereas a mediocre (not bad, just not gifted) one can write good Ada that's at least as efficient, readable and more maintainable. > Modern APL supports such control structures as IF/ElseIF/Else/Endif; > For/EndFor/ Select/Case/Case/EndSelect; Repeat/Until; and Do While/EndDo > which can aid the programmer in creating clear code, and can often improve > run-time speed as well. Thanks, I didn't know this. (ie that modern dielects of APL had this capability, not the worth of same). What's the situation vis-a-vis Standards, ie compatability between brand-X APL and brand-Y? -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` FRS DES @ 1997-10-20 0:00 ` Lawrence Kirby 1997-10-20 0:00 ` Kaz 1997-10-21 0:00 ` Programming language vote - results Alan E & Carmel J Brain 1997-10-21 0:00 ` Randy MacDonald ` (2 subsequent siblings) 4 siblings, 2 replies; 147+ messages in thread From: Lawrence Kirby @ 1997-10-20 0:00 UTC (permalink / raw) In article <344BCED0.2D51@dynamite.com.au> aebrain@dynamite.com.au "Alan E & Carmel J Brain" writes: ... >Hence my preference for Ada. When listening to C weenies - er - >enthusiasts talking about how their code is so tight, so efficient, and >above all so impenetrable that it's obviously superior to another >solution (in Ada so clear that "Any Fool could have written that"), I >have to take a dried-frog pill and count to 10. I don't know what sort of C programmers you talk to but that is *not* the sort of approach advocated on comp.lang.c. Here we're interested in code that is portable and clear. Optimisation is only a secondary issue, the most important aspect of that is choosing the right algorithm. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Lawrence Kirby @ 1997-10-20 0:00 ` Kaz 1997-10-21 0:00 ` Alan E & Carmel J Brain 1997-10-23 0:00 ` Ada Readability (Re: Programming language vote - results) Ray Blaak 1997-10-21 0:00 ` Programming language vote - results Alan E & Carmel J Brain 1 sibling, 2 replies; 147+ messages in thread From: Kaz @ 1997-10-20 0:00 UTC (permalink / raw) In article <877355167snz@genesis.demon.co.uk>, Lawrence Kirby <fred@genesis.demon.co.uk> wrote: >In article <344BCED0.2D51@dynamite.com.au> > aebrain@dynamite.com.au "Alan E & Carmel J Brain" writes: > >... > >>Hence my preference for Ada. When listening to C weenies - er - >>enthusiasts talking about how their code is so tight, so efficient, and >>above all so impenetrable that it's obviously superior to another >>solution (in Ada so clear that "Any Fool could have written that"), I >>have to take a dried-frog pill and count to 10. > >I don't know what sort of C programmers you talk to but that is *not* >the sort of approach advocated on comp.lang.c. Here we're interested >in code that is portable and clear. Optimisation is only a secondary >issue, the most important aspect of that is choosing the right >algorithm. In any case, Ada's clarity of expression is extremely overemphasized by Ada ween^H^H^H^Hadvocates. Ada source has very little to guide the eye, due to its lack of the use of concise graphical symbols. Blocks delimited by BEGIN and END simply do not nest visually. The comments introduced by -- simply don't stand out very well. The input character set is excessively restricted, and simple () parentheses are too overloaded in meaning because {} and [] aren't available (is x(y) a function call or an array ref?). Can you say dull? As a result, your brain has to do a lot more analysis when reading code, since you have to subconsciously check the syntax and even some semantics to glean information that could be lexically determined. Ada programs tend to be verbose and amorphous looking, qualities which occlude the meaning. (I'm talking about conventionally formatted programs, too e.g. GNAT sources. It wouldn't be fair to pick a purposely obfuscated example, just like it wouldn't be fair to choose an obfuscated C example.) Although Ada is great, I wouldn't advocate it on grounds of lexical or syntactic convenience or readability. You'd have to be crazy! -- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Kaz @ 1997-10-21 0:00 ` Alan E & Carmel J Brain 1997-10-23 0:00 ` Ada Readability (Re: Programming language vote - results) Ray Blaak 1 sibling, 0 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-21 0:00 UTC (permalink / raw) Kaz wrote: > >>Hence my preference for Ada. When listening to C weenies - er - > >>enthusiasts talking about how their code is so tight, so efficient, and > >>above all so impenetrable that it's obviously superior to another > >>solution (in Ada so clear that "Any Fool could have written that"), I > >>have to take a dried-frog pill and count to 10. > In any case, Ada's clarity of expression is extremely overemphasized > by Ada ween^H^H^H^Hadvocates. The word you're looking for is "Fanatics". As in people who are so busy fighting, they've forgotten what they're fighting for. I have been known to suffer from this myself, as you may have guessed, but I try to keep it in check. Sometimes it's difficult. > Ada source has very little to guide the eye, due to its lack of the use of > concise graphical symbols. Blocks delimited by BEGIN and END simply do not > nest visually. Concur. Chroma keying helps, as it does in any similar language. But even {} is not really good, unless used in the style xxxxxxx { xxxx xxxxx } rather than xxxxxxx { xxxx xxxxx } > The comments introduced by -- simply don't stand out very well. As opposed to // ? Have to think about this one, I can't see there's much to choose. */ and /* on the other hand, seem significantly worse. But what about other languages/methods? How can this be done better? Over 2 U for suggestions. > The input character set is excessively restricted, and simple () > parentheses are too overloaded in meaning because {} and [] aren't available > (is x(y) a function call or an array ref?). Does it matter? Sometimes, yes, it does, and the overload is then a right pain. Other times, the degree of abstraction that is optimal is such that you don't need to know, and this is more often the case in the domains I've been working in. For example, TheGuestList(x) could be: a function that examines a database on system 345 then assembles the name into a record, then makes a call to a server outside the system to find the dietary restrictions, then after completion asks for operator input from another terminal so we can allocate a seat , or it could be a simple reference to an array. In either case though, what you end up with is a guest and the data. How that's done, especially on a distributed system where the data is all over the place, is irrelevant to the issue. More to the point, you can make a system where everything is hard-coded in a table and get your segment working correctly, while the team(s) doing the server and HCI get their act together 2 months late. The fact that other languages have this problem, and worse, is immaterial. > As a result, your brain has to do a lot more analysis when reading code, > since you have to subconsciously check the syntax and even some semantics > to glean information that could be lexically determined. Excellent point, Sir! Agree that all languages I've seen have this problem. Some worse than others, eg fred*bill; - declaration or multiplication? > Ada programs tend to be verbose and amorphous looking, qualities which occlude > the meaning. (I'm talking about conventionally formatted programs, too e.g. > GNAT sources. It wouldn't be fair to pick a purposely obfuscated example, > just like it wouldn't be fair to choose an obfuscated C example.) Partial agreement. Example: A loop through an enumerated type (this is fairly common to a lot of problems, right?) C++ (with Hungarian-like Notation) //---------------------------------------------------------- enum TrafficLight_E [ Red_KE = 1, Amber_KE, Green_KE ]; const MaxTrafficLight_K = Green_KE + 1; for (int index = 1; index < MaxTrafficLight_K ; index++) { // some statements } //---------------------------------------------------------- compared with: Ada (with TypeRecord notation) --/////////////////////////////////////////////////////////// type TrafficLightType is (Red, Amber, Green); for index in TrafficLightType loop -- some statements end loop; --/////////////////////////////////////////////////////////// In some ways, the C++ is more verbose, is it not? > Although Ada is great, I wouldn't advocate it on grounds of lexical or > syntactic convenience or readability. You'd have to be crazy! To me, in the above example, the Ada is more readable. And a heck of a lot easier to type. Examples are always suspect, however, and I agree completely that you can always find a pathological case. Yet to me, this one is not atypical: The Hungarian Notation for C++ seems neccessary to me, since in C++ you're vitally interested in the representation. Sure, it's a maintenance nightmare when an int changes to a long, but the benefits far outway the disadvantages. At least IMHO. In Ada, you've got better things to worry about than the representation, as a general rule. And when you do need it, you use a representation clause, such as one that makes Red equal to (binary) 100, Amber to 010 and Green to 001, as they may well do if you're controlling/reading via a parallel port. Your thoughts? I'm especially interested since you obviously know something about Ada-83 or -95 as well as C/C++. Unlike most critics, I hasten to add. Are you familiar with APL too? The comment symbol there is not exactly obvious! -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Ada Readability (Re: Programming language vote - results) 1997-10-20 0:00 ` Kaz 1997-10-21 0:00 ` Alan E & Carmel J Brain @ 1997-10-23 0:00 ` Ray Blaak 1 sibling, 0 replies; 147+ messages in thread From: Ray Blaak @ 1997-10-23 0:00 UTC (permalink / raw) kaz@latte.cafe.net (Kaz) writes: >Ada source has very little to guide the eye, due to its lack of the use of >concise graphical symbols. Blocks delimited by BEGIN and END simply do not >nest visually. The comments introduced by -- simply don't stand out very >well. The input character set is excessively restricted, and simple () >parentheses are too overloaded in meaning because {} and [] aren't available >(is x(y) a function call or an array ref?). Can you say dull? >As a result, your brain has to do a lot more analysis when reading code, >since you have to subconsciously check the syntax and even some semantics >to glean information that could be lexically determined. I would suggest that this is a subjective matter. For me Ada's verbose constructs stand out much better than C/C++'s, simply because there is an english-like way to read them. It is really a matter of what you are used to; once your brain is wired for a language, it can see it easily. As for needing to know the semantics, I would say that the situation is much worse in C++, where a function call might in fact be a constructor, implicit construction and type coversions are happening, and almost all operators can be user defined. Note that not knowing if x(y) is a function call or an array can be an advantage in that it need not matter how the mapping is implemented. Consider a look up table that starts off being implemented as a succinctly coded function, but is later changed to be a straight array for efficiency reasons. Client usage will not have to change. >Although Ada is great, I wouldn't advocate it on grounds of lexical or >syntactic convenience or readability. You'd have to be crazy! Call me crazy then. Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Lawrence Kirby 1997-10-20 0:00 ` Kaz @ 1997-10-21 0:00 ` Alan E & Carmel J Brain 1 sibling, 0 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-21 0:00 UTC (permalink / raw) Lawrence Kirby wrote: > >Hence my preference for Ada. When listening to C weenies - er - > >enthusiasts talking about how their code is so tight, so efficient, and > >above all so impenetrable that it's obviously superior to another > >solution (in Ada so clear that "Any Fool could have written that"), I > >have to take a dried-frog pill and count to 10. > > I don't know what sort of C programmers you talk to but that is *not* > the sort of approach advocated on comp.lang.c. Here we're interested > in code that is portable and clear. Optimisation is only a secondary > issue, the most important aspect of that is choosing the right > algorithm. I've noticed that often the type of views espoused on comp.lang.c are, if I may say so, both highly professional and alas, atypical. At least in my experience (in 3 continents and 4 companies). -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` FRS DES 1997-10-20 0:00 ` Lawrence Kirby @ 1997-10-21 0:00 ` Randy MacDonald 1997-10-22 0:00 ` Don Guinn 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-23 0:00 ` Programming language vote - results Jack Rudd 1997-10-25 0:00 ` Peter Seebach 4 siblings, 2 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-21 0:00 UTC (permalink / raw) In article <344BCED0.2D51@dynamite.com.au>, aebrain@dynamite.com.au wrote: >Randy MacDonald wrote: >> So, where's the code? Sounds like a challenge. >No. Please. I'm begging. Thus you consider your security code a failure? >I've spent the better part of my professional >life trying to get rid of the "fastest gun in the west" mentality of >programming. Given that most languages have built in viscosity, this is probably a wise course. >"There are two ways to write a program: Either make it so complex, >there's nothing obviously wrong, or so simple that there's obviously >nothing wrong." The mathematical nature ("everything is either trivial or impossible") of software is, regrettably, still in the future. A middle ground still exists. >Hence my preference for Ada. When listening to C weenies - er - >enthusiasts talking about how their code is so tight, so efficient, and >above all so impenetrable that it's obviously superior to another >solution (in Ada so clear that "Any Fool could have written that"), This is the claim COBOL made also. I don't believe that one either. My impression is that if an Ada program is clear, it probably isn't being used for its intended purpose, i.e. an embedded program. > I have to take a dried-frog pill and count to 10. In my younger and more >foolish days, I was of a like mind. >Now I think that APL has a place, >but only in small, one-use throw-aways, We, and those of our clients who have used our "one-use throw-away" software for time now measureable in decades would probably differ on this. As one who has built these systems, the >and where terseness if vital (as >in downloading complex programs over low-bandwidth data links). If that were true, Java wouldn't exist. >Probably other, similar areas as well. I'm glad it exists, as I'd hate to > have to invent it! >I once made the mistake of lending one of these C Hackers my old copy of >"Structured Programming in APL" (a title that still leaves me gasping at >the Oxymoron), and he's now a confirmed APL enthusiast. The structure is in the data, and more recently in the code. A nice property of APL/J programs is that, where a structured look appears, for example, where a series of lines have parallel structure, the similarity can be factored out, leaving a series of individually unique lines. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-21 0:00 ` Randy MacDonald @ 1997-10-22 0:00 ` Don Guinn [not found] ` <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com> 1997-10-29 0:00 ` Programming language vote - results Randy MacDonald 1997-10-25 0:00 ` Alan E & Carmel J Brain 1 sibling, 2 replies; 147+ messages in thread From: Don Guinn @ 1997-10-22 0:00 UTC (permalink / raw) Why is it OK to spend a whole morning understanding a couple pages of FORTRAN code, yet it is unreasonable to spend the same amount of time with a 2-liner in APL or J which does the same thing? Don Guinn donguinn@hal-pc.org ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com>]
* Re: Programming language vote - results [not found] ` <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com> @ 1997-10-29 0:00 ` FRS DES 1997-10-29 0:00 ` Don Guinn 1 sibling, 0 replies; 147+ messages in thread From: FRS DES @ 1997-10-29 0:00 UTC (permalink / raw) In article <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com>, "D.H. Kelly" <dkelly@nanaimo.ark.combull> writes: >_______________________________ >I prefer to use APL but I have long ago realized that it is beneficial to >spread it out a bit rather than use very complex 1 or 2 liners. It might >make it possible to figure the program out in a couple of minutes rather >than hours - especially if properly commented. APL is great for getting >things done concisely and effectively but that is no excuse for obscurity. >The delight many take in writing one line recursive programs, etc, actually >turns others off so that they miss the real usefullness of the language. >- I agree. I never write one-line loops or recursive functions -- there is no good reason to do so. If there were, in a particular case, I would probably add 4-5 lines of comments explainging what the fn did and why. APL is terse, compared to manyn other languages, but well written APL is rarely as ters as the language theoritically permits. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results [not found] ` <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com> 1997-10-29 0:00 ` FRS DES @ 1997-10-29 0:00 ` Don Guinn 1997-10-29 0:00 ` Shmuel (Seymour J.) Metz 1997-10-31 0:00 ` Documenting Code (was:Programming language vote - results) Alan E & Carmel J Brain 1 sibling, 2 replies; 147+ messages in thread From: Don Guinn @ 1997-10-29 0:00 UTC (permalink / raw) D.H. Kelly wrote: > > Don Guinn wrote: > Why is it OK to spend a whole morning understanding a couple pages of > FORTRAN code, yet it is unreasonable to spend the same amount of time > with a 2-liner in APL or J which does the same thing? > _______________________________ > I prefer to use APL but I have long ago realized that it is beneficial to > spread it out a bit rather than use very complex 1 or 2 liners. It might > make it possible to figure the program out in a couple of minutes rather > than hours - especially if properly commented. APL is great for getting > things done concisely and effectively but that is no excuse for obscurity. > The delight many take in writing one line recursive programs, etc, actually > turns others off so that they miss the real usefullness of the language. > -- > Don Kelly > dkelly@nanaimo.ark.combull > remove the "bull " to reply _________________________________ You are right. It does make it easier to read if things are spread out. Lately I have had to spend a fair amount of time studying Visual Basic and was impressed on how Microsoft and other writers could fill a thick book with so little information. I was able to read the books faster than I read paperbacks because after I saw the same information the third time I could simply scan it looking for possible differences. Not so with APL and J. Redundancy is minimal and it takes a long time to read the manuals. The same thing happens in code. Visual Basic, C etc. are voluminous in the size of the source. The source for a small application go on and on and can be read rapidly because the information content is so low. A manager looks at the size of the source and is impressed! Don't tell him that most of it is boilerplate built by a wizard. That out of the 20 to 100 pages of source there resides two or three pages of original code. Now that same manager comes in and sees that you're spending days working on a program in APL which, if printed, would fill only a few pages. He is not impressed! You are obviously not producing. Nevermind that both produce the same result. As far as documenting code. Documentation is wonderful when it adds information and insight on what the program does. I have seen too many programs full of documentation which does nothing but repeat what is already stated in the code itself. It's as if the person who wrote it can't read his own code. Which brings up how programming is being taught. We go to classes to learn how to write computer programs. Where does one go to learn how to read programs? Ever see a course in reading computer programs. Actually there are, but they're never called that. They are called analysis and debugging courses and no applications programmer would ever want to go to. I'll never forget the little red book for a linear algebra course I took. It was no bigger than the J dictionary. We would spend an entire evening on one page. Does that mean that it was not well written? Documentation needs to explain the concepts used in an application. It should provide definitions of terms (variables) and possible things to watch out for. But it should not have to translate the source code into English. It should not be measured by the pound. Don Guinn donguinn@hal-pc.org ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-29 0:00 ` Don Guinn @ 1997-10-29 0:00 ` Shmuel (Seymour J.) Metz 1997-10-31 0:00 ` Documenting Code (was:Programming language vote - results) Alan E & Carmel J Brain 1 sibling, 0 replies; 147+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-10-29 0:00 UTC (permalink / raw) Don Guinn wrote: > > As far as documenting code. Documentation is wonderful when it adds > information and insight on what the program does. I have seen too many > programs full of documentation which does nothing but repeat what is > already stated in the code itself. It's as if the person who wrote it > can't read his own code. When I was drafted into teaching a programming course I told my students that I would take points off for any comments that didn't clarify the program and for any code that I couldn't understand. I'm older and wiser now; if I have to teach another course I will also insist that a randomly selected student be able to understand the code. > Documentation needs to explain the concepts used in an application. It > should provide definitions of terms (variables) and possible things to > watch out for. But it should not have to translate the source code into > English. It should not be measured by the pound. Amen! -- Shmuel (Seymour J.) Metz Senior Software SE The values in from and reply-to are for the benefit of spammers: reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com, user smetz. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-29 0:00 ` Don Guinn 1997-10-29 0:00 ` Shmuel (Seymour J.) Metz @ 1997-10-31 0:00 ` Alan E & Carmel J Brain 1997-10-30 0:00 ` Charles Lin 1997-11-01 0:00 ` Randy MacDonald 1 sibling, 2 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-31 0:00 UTC (permalink / raw) Don Guinn wrote: > > Don Guinn wrote: > > Why is it OK to spend a whole morning understanding a couple pages of > > FORTRAN code, yet it is unreasonable to spend the same amount of time > > with a 2-liner in APL or J which does the same thing? > > I prefer to use APL but I have long ago realized that it is beneficial to > > spread it out a bit rather than use very complex 1 or 2 liners. > You are right. It does make it easier to read if things are spread out. > As far as documenting code. Documentation is wonderful when it adds > information and insight on what the program does. I have seen too many > programs full of documentation which does nothing but repeat what is > already stated in the code itself. It's as if the person who wrote it > can't read his own code. > Documentation needs to explain the concepts used in an application. It > should provide definitions of terms (variables) and possible things to > watch out for. But it should not have to translate the source code into > English. It should not be measured by the pound. My viewpoint: If one is using a language that is "terse", such as APL, where WHAT the thing does is not immediately obvious, then a quickly-read line which explains what the code is _supposed_ to be doing is very helpful. At first glance, it can tell a reader what the code does, more quickly than ploughing through cryptic things like GHTransmit(const char* const X); which is basically a read-only string input to a function. Secondly, comments often tell what the program is _supposed_ to do, not always what it does. This means that a quick-scan of the comments only will not reveal a bug. OTOH a more careful reading, which would reveal the difference between actual and intended, automatically finds the bug and suggests a solution. OK, that's it for documenting WHAT the code does. In many, less terse languages, comments are more useful for describing _why_ something is done. For example (in Ada-83); with Tracker; -- package for Radar Trackers only! with TacticalPicture; -- what's the environment we're in procedure AllocateRadarTrackers (TheTrackerStates in Tracker.StateTableType, TheTacticalPicture in TacticalPicture.BasicRecordType, ResultantTrackerCommands out Tracker.CommandListType) is -- Procedure that, given a table of the current radar tracker -- states, and the tactical picture, decides on what commands -- to give to the radar trackers. -- These commands are then expected to be transmitted to the -- trackers by another procedure. -- Exceptions that can be raised here are: -- AllTrackersKaputException ( The Trackers are all KO ) -- UnexpectedErrorException ( Bug or hardware fault) begin -- and so on and so on end; Note that in this (deliberately) verbose and non-terse example, the variables, procedure, exception and type names are self-explanatory. To some degree, the code _is_ the comment, at least on "what it does". Most of the comments "as such" are either explanations of the intention, or give implications of events. A terser piece of code that is exactly hemeomorphic is: with Trk; with TacPic; procedure TCmds ( T in Trk.Lst, TP in TacPic.TP, Cmds out Trk.Cmds ) is -- Procedure that, given a table of the current radar tracker -- states (Trk.Lst), and the tactical picture (TacPic.TP), decides on -- what commands to give to the radar trackers (Trk.Cmds). -- These commands are then expected to be transmitted to the -- trackers by another procedure. -- Exceptions that can be raised here are: -- ATK ( _A_ll _T_rackers _K_O ) -- FUBAR ( Bug or hardware fault) begin -- etc etc end; Note that despite some bad names, the comments explain what's happening. Without the comments, this would be so cryptic as to be baroque. A translation into C++ would be something like #include TP.h; // Tactical Picture Class #include Trk.h; // Tracker Class Trk::CmdList* TCmds( const Trk::Lst* const TL, const TP::Data* const TP) // Procedure that, given a table of the current radar tracker // states (Trk::Lst), and the tactical picture (TP::TP), decides on // what commands to give to the radar trackers (Trk::Cmds). // These commands are then expected to be transmitted to the // trackers by another procedure. // It's assumed that TL and TP are both going to be used later, so // the pointers have been made const, as well as the data pointed to. // Exceptions that can be thrown here are: // ATK ( _A_ll _T_rackers _K_O ) // FUBAR ( Bug or hardware fault) { // etc etc } When using Hungarian Notation, a lot more verbosity sneaks in, as in the first Ada example, which has an equivalent of Hungarian Notation in it ( Tracker.StateTableType rather than Tracker.State for example) How NOT to do it (in any language): procedure P_12_356( X99 in integer ) is NumberOfBananas : integer; -- The number of Bananas NumberOfBaskets : integer; -- The number of Baskets F : float; begin -- and so on in this deliberately BAD example -- which shows that it's possible to write really bad Ada, -- and make comments that are both verbose and useless, -- but you have to really, really work at it! end; I still for the life of me can't understand why C++ is so popular, yet Ada is described as obsolete, etc etc when for a lot of purposes, Ada is C++ with (usually more) clarity, power and safety belts. Certainly in my experience C++ programmers who've had some exposure to Ada have an advantage over the rest. But never mind. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-31 0:00 ` Documenting Code (was:Programming language vote - results) Alan E & Carmel J Brain @ 1997-10-30 0:00 ` Charles Lin 1997-10-30 0:00 ` James L. Ryan 1997-10-31 0:00 ` Robert Bernecky 1997-11-01 0:00 ` Randy MacDonald 1 sibling, 2 replies; 147+ messages in thread From: Charles Lin @ 1997-10-30 0:00 UTC (permalink / raw) One problem with documenting code is that it is often at too fine a level. That is, you document individual functions or classes, when what the user really wants is the overall structure of the code, as well as how this solution solves the problem. Sometimes, one practically wants an overview manual of the code, including the approach to the solution, the data structures used, and their interactions. So, you might have a, say, CAD tool. You might have objects that stand for shapes (rectangles, circles), objects that stand for treating sevearal base objects as a whole. Objects to keep track of the state of what is being done (draw, insert, delete, copy, etc). Most people would simply comment each of the classes, but this still gives only a vague idea of how it all fits together. I think that producing such a general document might also be useful for implementors, forcing them to put into words, ideas they have in their head. This is esp. important for people who write code for themselves (or in classes). By placing idea to paper, they may clarify muddy thoughts which lead to muddy designs. -- Charles Lin clin@cs.umd.edu ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-30 0:00 ` Charles Lin @ 1997-10-30 0:00 ` James L. Ryan 1997-10-31 0:00 ` Robert Bernecky 1997-10-31 0:00 ` Robert Bernecky 1 sibling, 1 reply; 147+ messages in thread From: James L. Ryan @ 1997-10-30 0:00 UTC (permalink / raw) About a year ago I started using (admittedly with reluctance!) the then new control structures which appeared in Dyalog APL. (Dyadic had copied the definitions implemented earlier in APL/2000.) After having used them, I find that they themselves provide somewhat of a self-commenting structure. That is, I can find my way around in a routine with such structures with greater ease than in a similar routine written with "conventional" means of flow control. -- James L. Ryan -- bosworth@waterw.com ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-30 0:00 ` James L. Ryan @ 1997-10-31 0:00 ` Robert Bernecky 0 siblings, 0 replies; 147+ messages in thread From: Robert Bernecky @ 1997-10-31 0:00 UTC (permalink / raw) To: James L. Ryan James L. Ryan wrote: > About a year ago I started using (admittedly with reluctance!) the then > new control structures which appeared in Dyalog APL. (Dyadic had copied > the definitions implemented earlier in APL/2000.) After having used them, > I find that they themselves provide somewhat of a self-commenting > structure. That is, I can find my way around in a routine with such > structures with greater ease than in a similar routine written with > "conventional" means of flow control. I agree. I implemented most of APEX using them and found code MUCH easier to read and maintain. Two other points: a. Control structures make it easier to generate efficient compiled code than I can with GOTO. APEX generates code for these that matches or beats good hand-coded FORTRAN on many applications. b. Control structures make your INTERPRETED code run faster than GOTOd code. See my APL95 paper on dynamic programming in APL for an example of a 25% speedup in interpreted execution time by use of control structures. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-30 0:00 ` Charles Lin 1997-10-30 0:00 ` James L. Ryan @ 1997-10-31 0:00 ` Robert Bernecky 1 sibling, 0 replies; 147+ messages in thread From: Robert Bernecky @ 1997-10-31 0:00 UTC (permalink / raw) To: Charles Lin Charles Lin wrote: > One problem with documenting code is that it is often at too fine > a level. That is, you document individual functions or classes, when > what the user really wants is the overall structure of the code, as > well as how this solution solves the problem. Sometimes, one practically > wants an overview manual of the code, including the approach to the > solution, the data structures used, and their interactions. Indeed. Consider the usual situation: You get hired into a project with these characteristics: - anyone who designed the original system has been laid off or has gone to greener pastures. - the system has been maintained for the last 3 years by apprentice programmers whose previous job was mechanic in a muffler shop. - part X of the system is chewing entire mainframes and growing at 15% per month. The documentation you want to see (and rarely ever do) is: - What is the INTENT of part X? E.g., in a matrix inversion routine, you want something of the form: "This function solves sparse linear systems. We don't use the built-in DOMINO primitive to do this, because the arrays have 250,000 rows and domino doesn't know from sparseness today." - What is going to break if I change/replace/rewrite this? In APL, this is a pain to determine, because of APL's prehistoric dynamic scoping rules. You have to know everyone who calls you (if you use/set a variable that's global to you), and you have to know everyone you call (if you set or use any variable), because ALL of your variables are visible to everyone you call. My approach lately has been to feed the entire application into the APEX APL compiler, which determines this as part of the setup for a later data flow analysis phase. In a large system, it's hard because you end up with . Black-box subapplications that (for historical reasons of wee, tiny main memories) set global/semi-global variables. No, you do not have access to the source code for the black box. . huge function paging files that are either unavailable or undecypherable. The advent of code maintenance systems such as LOGOS help the latter, but not the former. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-10-31 0:00 ` Documenting Code (was:Programming language vote - results) Alan E & Carmel J Brain 1997-10-30 0:00 ` Charles Lin @ 1997-11-01 0:00 ` Randy MacDonald 1997-11-01 0:00 ` Robert Dewar 1 sibling, 1 reply; 147+ messages in thread From: Randy MacDonald @ 1997-11-01 0:00 UTC (permalink / raw) In article <3459A84A.246@dynamite.com.au>, aebrain@dynamite.com.au wrote: >I still for the life of me can't understand why C++ is so popular, yet >Ada is described as obsolete, etc etc when for a lot of purposes, Ada is >C++ with (usually more) clarity, power and safety belts. Perhaps because most serious implementations have a large price tag attached, and are not subject to marketing/price wars like those that have boosted the fortunes of BASIC, Pascal, C and C++. If Microsoft had actually succeeded with an APL implementation, this would probably have led to a much more interesting present. >Certainly in my experience C++ programmers who've had some exposure to Ada >have an advantage over the rest. But never mind. This I would tend to believe as an If-APL-did-not-exist-I-would-be-using-Ada person. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-11-01 0:00 ` Randy MacDonald @ 1997-11-01 0:00 ` Robert Dewar 1997-11-03 0:00 ` Jon S Anthony 0 siblings, 1 reply; 147+ messages in thread From: Robert Dewar @ 1997-11-01 0:00 UTC (permalink / raw) Randy said of Ada implementations <<Perhaps because most serious implementations have a large price tag attached, and are not subject to marketing/price wars like those that have boosted the fortunes of BASIC, Pascal, C and C++. If Microsoft had actually succeeded with an APL implementation, this would probably have led to a much more interesting present.>> While this may have been true at one point, at this stage it is serious disinformation :-) There is a freely available implementation of Ada 95 that is widely used by major commercial customers. It is GNAT, the GNU Ada 95 compiler, part of the GCC system. GNAT is fully validated on a wide range of systems, and is in fact the *only* Ada 95 technology that implements the full Ada 95 language and passes 100% of the ACVC tests). GNAT is available freely on many mirror sites on the net (check out www.gnat.com for a list of sites). You might think that this kind of free availability would eliminate price competition, but nothing could be further from the truth! Aonix has an Ada 95 compiler for Windows NT/Win 95 and competes energetically with GNAT. Limited capability versions of the Aonix Object-Ada compiler are available for free downloading, and fully capable versions are sold at very low prices, fully comparable with the price scale established by MS and Borland for Pascal and C. Robert Dewar Ada Core Technologies (which provides commercial support for GNAT) I realize this is cross-posted rather widely, but when disinformation is spread widely, it seems appropriate to follow it up to all corresponding groups. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Documenting Code (was:Programming language vote - results) 1997-11-01 0:00 ` Robert Dewar @ 1997-11-03 0:00 ` Jon S Anthony 0 siblings, 0 replies; 147+ messages in thread From: Jon S Anthony @ 1997-11-03 0:00 UTC (permalink / raw) dewar@merv.cs.nyu.edu (Robert Dewar) writes: > Randy said of Ada implementations > > <<Perhaps because most serious implementations have a large price tag > attached, and are not subject to marketing/price wars like those that > have boosted the fortunes of BASIC, Pascal, C and C++. If Microsoft > had actually succeeded with an APL implementation, this would > probably have led to a much more interesting present.>> > > While this may have been true at one point, at this stage it is serious > disinformation :-) > > There is a freely available implementation of Ada 95 that is widely used Well, I'm a big Ada supporter and user, but I have to say that this is not quite as true as it seems - at least on UNIX. Certainly, if you are developing a product you will want to have support for the implementation vehicle. For good or ill, that support _is_ more expensive than for C/C++ stuff. This is recent "voice of experience" speaking here. > price competition, but nothing could be further from the truth! Aonix > has an Ada 95 compiler for Windows NT/Win 95 and competes energetically > with GNAT. I would say that the Aonix NT ObjectAda compiler _is_ definitely competitive in price with any C/C++ kind of stuff and the capabilities are way beyond anything in C/C++. That's for the complete enterprise level support package. Hat's off to Aonix for this extremely useful product line/pricing offering. /Jon -- Jon Anthony Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-22 0:00 ` Don Guinn [not found] ` <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com> @ 1997-10-29 0:00 ` Randy MacDonald 1 sibling, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-29 0:00 UTC (permalink / raw) In article <344DEAA9.5115@hal-pc.org>, donguinn@hal-pc.org wrote: >Why is it OK to spend a whole morning understanding a couple pages of >FORTRAN code, yet it is unreasonable to spend the same amount of time >with a 2-liner in APL or J which does the same thing? A couple of reasons come to mind: 1. APL hides a lot of the detail within primitives. Usually the result is the focus as opposed to the algorithm. 2. APL combines a lot of what would be separate cases in FORTRAN into a single case. Essentially there is one set of numbers in APL, where in FORTRAN, code varies for each separate data type, and the semantics of expressions like: C = A / B K = I / J can produce quite different results. Note that I am assuming the I..N as INTEGER rule for FORTRAN. 3. APL can remove the need for temporary variables, or control variables or index variables. In terms of what one would call a reasonable period for understanding, it is also true that APL tends to match the subject matter, while FORTRAN also adds the artifacts of the language as things to be understood. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-21 0:00 ` Randy MacDonald 1997-10-22 0:00 ` Don Guinn @ 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-26 0:00 ` functionality of Java (was Re: Programming language vote - results) Randy MacDonald 1 sibling, 1 reply; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-25 0:00 UTC (permalink / raw) Randy MacDonald wrote: > > >> So, where's the code? Sounds like a challenge. > >No. Please. I'm begging. > Thus you consider your security code a failure? Nope. I just don't feel any tearing need to a) look up the hard copy from 1981, b) transcribe the APL into ASCII equivalents for posting and c) Expose to public view a piece of work I'm not particularly proud of. Don't think anyone could learn from it, and I'm not being paid, so why devote the time? > >Hence my preference for Ada. When listening to C weenies - er - > >enthusiasts talking about how their code is so tight, so efficient, and > >above all so impenetrable that it's obviously superior to another > >solution (in Ada so clear that "Any Fool could have written that"), > > This is the claim COBOL made also. I don't believe that one either. > My impression is that if an Ada program is clear, it probably isn't being > used for its intended purpose, i.e. an embedded program. Based upon what evidence? (No, this is not sarcasm, it's a request for info that might teach me something, if it can penetrate my thick skull). My own experience on embedded systems these past 12 years or so directly contradicts this. If you wish, I'll quote some code fragments. I'd be interested in whether you think them clear, and if not, why not. > We, and those of our clients who have used our "one-use throw-away" > software for time now measureable in decades would probably differ on > this. Fair enough. I'm sure you're correct (heck, there are even people who think RPG is just dandy). Can you tell me why though? > >and where terseness if vital (as > >in downloading complex programs over low-bandwidth data links). > > If that were true, Java wouldn't exist. ??? Something with the terseness of APL, if it had the functionality of Java plus a fair bit more, would be ideal. As it is, Java is flavour-of-the-month, but has not been shown to be appropriate for anything larger than relatively small applications. But now we're straying into territory more appropriate to comp.lang.java, and I'm adducing vague generalities without giving evidence, so I'd rather not continue here. > The structure is in the data, and more recently in the code. A nice property > of APL/J programs is that, where a structured look appears, for example, where > a series of lines have parallel structure, the similarity can be factored out, > leaving a series of individually unique lines. Please elucidate. A code fragment illustrating this would be greatly appreciated. My thanks for your time and effort. I think, considering the cross-post, an equivalent in C, C++ and Ada-95 would be useful too. I'll add those, if you wish (or maybe some reader who's more enthusiastic about C, C++ might be willing to). -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* functionality of Java (was Re: Programming language vote - results) 1997-10-25 0:00 ` Alan E & Carmel J Brain @ 1997-10-26 0:00 ` Randy MacDonald 0 siblings, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-26 0:00 UTC (permalink / raw) In article <3451AE2C.7F7A@dynamite.com.au>, aebrain@dynamite.com.au wrote: >Randy MacDonald wrote: > >> >and where terseness if vital (as >> >in downloading complex programs over low-bandwidth data links). >> >> If that were true, Java wouldn't exist. > >??? If a terse language was what was ideal for downloading complex programs over these slow links, why did a verbose (relative to APL) language become the darling of this platform. > Something with the terseness of APL, if it had the functionality of >Java plus a fair bit more, Given that most of the functionality of Java is in the "built in" objects, or the default classes (since otherwise, Java is just another Algoloid language, although it DOES allow objects as the results of functions...) all APL needs is a sufficiently powerful "default workspace" containing specific functionality. J, for example, contains in its default profile, an impressive amount of functionality: program management tools, GUI management tools,... >would be ideal. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Alan E & Carmel J Brain ` (2 preceding siblings ...) 1997-10-21 0:00 ` Randy MacDonald @ 1997-10-23 0:00 ` Jack Rudd 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-25 0:00 ` Peter Seebach 4 siblings, 1 reply; 147+ messages in thread From: Jack Rudd @ 1997-10-23 0:00 UTC (permalink / raw) Alan E & Carmel J Brain wrote: > > ... Now I think that APL has a place, > but only in small, one-use throw-aways, and where terseness if vital (as > in downloading complex programs over low-bandwidth data links). Probably > other, similar areas as well. I'm glad it exists, as I'd hate to have to > invent it! > I'm an algorithm developer. The greatest value of APL for me is in rapid prototyping. Usually I can prototype a new application or subsystem myself, quickly, without need of programmers. Almost never is there need for more than a few APLers. Using a scalar language, one would have to triple the number of project members, thus quadrupling the amount of pairwise miscommunication among project members. I've tried Ada for prototyping. There's nothing rapid about it. Jack Rudd ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-23 0:00 ` Programming language vote - results Jack Rudd @ 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-25 0:00 ` Kaz 1997-10-29 0:00 ` Jack Rudd 0 siblings, 2 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-10-25 0:00 UTC (permalink / raw) Jack Rudd wrote: > > Alan E & Carmel J Brain wrote: > > > > ... Now I think that APL has a place, > > but only in small, one-use throw-aways, ---->8------ > I'm an algorithm developer. The greatest value of APL for me is > in rapid prototyping. Concur completely, an excellent example of 1-use throw-away is when you're developing and testing an algorithm! APL is one heck of a good rapid prototyping language. In fact, for algorithm design, I can't think of one better. > I've tried Ada for prototyping. There's nothing rapid about it. Concur again. It's strengths are in large systems, which are designed to be maintainable over the long term, and "safe". -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-25 0:00 ` Alan E & Carmel J Brain @ 1997-10-25 0:00 ` Kaz 1997-10-26 0:00 ` FRS DES 1997-10-27 0:00 ` Robert Bernecky 1997-10-29 0:00 ` Jack Rudd 1 sibling, 2 replies; 147+ messages in thread From: Kaz @ 1997-10-25 0:00 UTC (permalink / raw) In article <3451AA9D.259C@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: >Concur completely, an excellent example of 1-use throw-away is when >you're developing and testing an algorithm! APL is one heck of a good >rapid prototyping language. In fact, for algorithm design, I can't think >of one better. > >> I've tried Ada for prototyping. There's nothing rapid about it. > >Concur again. It's strengths are in large systems, which are designed to >be maintainable over the long term, and "safe". Also, Ada does not require a ``space-cadet'' terminal. That is something to consider. Does APL still require a character set full of graphic symbols, or are there ``alternate spellings''? What is the latest status of APL as a standardized language? Is it possible to decompose a system written in APL into separately compiled modules? You will have to pardon me, because all I know about APL comes from a book dating back to 1972 or so. :) -- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-25 0:00 ` Kaz @ 1997-10-26 0:00 ` FRS DES 1997-10-27 0:00 ` Robert Bernecky 1 sibling, 0 replies; 147+ messages in thread From: FRS DES @ 1997-10-26 0:00 UTC (permalink / raw) In article <62te54$p4l$1@latte.cafe.net>, kaz@latte.cafe.net (Kaz) writes: > >Also, Ada does not require a ``space-cadet'' terminal. That is something to >consider. > Most modern APLs run on standard equipment. I write APL full-time on a Dell PC, with no special keyboard. >Does APL still require a character set full of graphic symbols, or are there >``alternate spellings''? What is the latest status of APL as a standardized >language? Is it possible to decompose a system written in APL into separately >compiled modules? > APL still uses special symbols, but this simply means one more font file on a windows (or mac) system. It is no harder to install and use an APL font than any other font. Most APL programs install one or more APL fonts for the user. I don't know what you mean by a "standardized language". Most implementations of APL adhere to the ISO standard for APL, just as most implementations of C adhere to the C standard. APL is not (normnally) compiled, so it can not be decomposed into compiled modules, seperately or not. An APL system can be decomposed into seperate modules in any of several ways, depending on the purpose involved. APL can call and be called by code written in other languages, such as in a DLL (in windows). >You will have to pardon me, because all I know about APL comes from a book >dating back to 1972 or so. :) While the core of the language is the same, *MUCH* has changed in APL since 1972. -David E. Siegel Software Developer, Financial Reporting Software (FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-25 0:00 ` Kaz 1997-10-26 0:00 ` FRS DES @ 1997-10-27 0:00 ` Robert Bernecky 1997-10-27 0:00 ` APL argument W. Wesley Groleau x4923 1997-10-28 0:00 ` Programming language vote - results Jan Karman 1 sibling, 2 replies; 147+ messages in thread From: Robert Bernecky @ 1997-10-27 0:00 UTC (permalink / raw) To: Kaz Kaz wrote: > In article <3451AA9D.259C@dynamite.com.au>, > Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: > Does APL still require a character set full of graphic symbols, or are there > ``alternate spellings''? What is the latest status of APL as a standardized > language? Is it possible to decompose a system written in APL into separately > compiled modules? a. APL still requires an oddball character set. I am now on week 9 of my latest effort of trying to make a Type 1 PostScript APL font work for getting my thesis into .pdf format. Languages derived from APL, such as J (www.jsoftware.com) and QNial use ascii, and not thus hampered. I suspect that if we [the APL design community] had not been so blind to the realities of ergonomics, psychology, and display engineering, that we would have abandoned the APL character set long ago, and perhaps thereby made APL a far more popular language. b. There is an extant ISO APL Standard, N8485, and a new extended language standard either pending acceptance or already accepted. Unfortunately, APL vendors are taking almost NO steps to make their products interoperable [The adoption of the APL2000 control structures by Dyadic represents a very desirable departure from the past in this area. I hope IBM and Soliton see the light and do likewise.]. In fact, they seem go to substantial lengths to ensure that their products are different enough that an application writer has almost zilch change of writing a highly portable application. Specific nasty areas include, but are not limited to: - Screen driver support - File handling - Error handling - Namespaces This NIH attitude is not a new thing. It's been going on since the dark ages. To be fair to the designers, I think they honestly feel that their approach is somehow better than the competition. This, however, does the APL user community a great disservice. c. It is possible to decompose an APL application into separately compilable modules, sort of. There are several ways this can be done, depending on your definitions of separately, compilable, and module. For example: - Dyadic Systems offers a namespace capability that lets you segregate subsystems (applications) into logically distinct spaces. This greatly simplifies merging subsystems into a single workspace, maintaining large systems, etc. - Iverson Software/Strand offer a similar capability within the J interpreter. - Snake Island Research's APEX APL compiler has the ability to compile APL into UNIX/Winnt executables or .DLL files. APEX is not yet a product, but an adjunct to our consulting services. - Products such as Soliton's logos provide many of the capabilities needed for large system development, such as checkout/checkin, hierarchical libraries, makfiles, etc. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: APL argument 1997-10-27 0:00 ` Robert Bernecky @ 1997-10-27 0:00 ` W. Wesley Groleau x4923 1997-10-28 0:00 ` Randy MacDonald 1997-10-28 0:00 ` Programming language vote - results Jan Karman 1 sibling, 1 reply; 147+ messages in thread From: W. Wesley Groleau x4923 @ 1997-10-27 0:00 UTC (permalink / raw) > a. APL still requires an oddball character set. I am now on week 9 of > my latest effort of trying to make a Type 1 PostScript APL font work > for getting my thesis into .pdf format. Even when it looks OK on screen, without an APL keyboard, it takes a while to train your mind and fingers what's what. Time to start editing your newsgroups lines!!! -- ---------------------------------------------------------------------- Wes Groleau, Hughes Defense Communications, Fort Wayne, IN USA Senior Software Engineer - AFATDS Tool-smith Wanna-be wwgrol AT pseserv3.fw.hac.com Don't send advertisements to this domain unless asked! All disk space on fw.hac.com hosts belongs to either Hughes Defense Communications or the United States government. Using email to store YOUR advertising on them is trespassing! ---------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: APL argument 1997-10-27 0:00 ` APL argument W. Wesley Groleau x4923 @ 1997-10-28 0:00 ` Randy MacDonald 0 siblings, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-28 0:00 UTC (permalink / raw) In article <3454DCF7.4D05@pseserv3.fw.hac.com>, "W. Wesley Groleau x4923" <wwgrol@pseserv3.fw.hac.com> wrote: >> a. APL still requires an oddball character set. I am now on week 9 of >> my latest effort of trying to make a Type 1 PostScript APL font work >> for getting my thesis into .pdf format. I'd be suprised if this hasn't been solved, over and over. If you could detail the nature of your problems, perhaps a cla'er has some suggestions... >Even when it looks OK on screen, without an APL keyboard, >it takes a while to train your mind and fingers what's what. This "while" is vastly overemphasized in importance, and is not even comparable to the effort of learning qwerty in the first place. Most APL implementations allow for a "union" keyboard, where ASCII gets top billing and the APL characters are tucked away behind the Alt- state. Once you remember that quad is Alt-L, jot is Alt-J (like that would be tough), rho is Alt+R, et cetera, you are pretty much back in business. I haven't used keycaps since the 80's. >Time to start editing your newsgroups lines!!! -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-27 0:00 ` Robert Bernecky 1997-10-27 0:00 ` APL argument W. Wesley Groleau x4923 @ 1997-10-28 0:00 ` Jan Karman 1997-10-28 0:00 ` Robert Bernecky 1 sibling, 1 reply; 147+ messages in thread From: Jan Karman @ 1997-10-28 0:00 UTC (permalink / raw) Bernecky's hypothesis "APL still requires an oddball character set "[..] "I suspect that if we [the APL design community] had not been so blind to the realities "of ergonomics, psychology, and display engineering, that we would have abandoned "the APL character set long ago, and perhaps thereby made APL a far more popular "language. is easily be refuted. Proof #1 It would have been as easy for APL vendors to deliver a free, suitable keyboard together with the interpreter as it is for canneries to stick a little key to the bottom of their cans in order to get access to the food inside. I beleive IBM did in the old days, or was it only caps?, and DEC and Data General had carefully designed decals, but you had to pay for it, presumed you knew the secret numbers to order them by. IBM abandoned this habit and even the decals disapeared from the boxes. Why? Perhaps, it didn't add any value to the interpreter. This was a "marketing-mix" solution. A trainee-salesman would have been able to sell the power and fun of APL against the disadvantages of the oddball characters ("See that little key sticked at the bottom? ... there's a deli inside!!"). Because knowledge of APL characters is only relevant to programmers, this would have solved the oddball character problem. If this had been really the problem it should have easily been solved Proof #2, by counter example, i.e. J Could you say e.g.: "Let's give APL common ASCII-characters and it would become as popular as Yahoo?" At the same speed you could say : "If we should colour Campari corn-yellow it would become as popular as beer." There's no need for 20,000,000 APL interpreters, but to solve some of the mudding with computer languages in the 21st century (NB! not just the first day) we'll badly need some powerful, symbolic language, as there are APL, J or K. J is too complicated and too confusing (private opinion) K is privately owned (there seems no desire to make it popular). APL is available, cheep ... and fun. "Stick more magic key to the can", I'd say. (Main gates : http://www.acm.org/sigapl or http://www.vector.org.uk ) ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-28 0:00 ` Programming language vote - results Jan Karman @ 1997-10-28 0:00 ` Robert Bernecky 1997-10-28 0:00 ` James L. Ryan 0 siblings, 1 reply; 147+ messages in thread From: Robert Bernecky @ 1997-10-28 0:00 UTC (permalink / raw) To: Jan Karman Jan Karman wrote: > Bernecky's hypothesis > > "APL still requires an oddball character set > "[..] > "I suspect that if we [the APL design community] had not been so blind to > the realities > "of ergonomics, psychology, and display engineering, that we would have > abandoned > "the APL character set long ago, and perhaps thereby made APL a far more > popular > "language. > is easily be refuted. > > Proof #1 > It would have been as easy for APL vendors to deliver a free, suitable > keyboard I am talking about history and what DID happen. There was no serious attempt by any vendor to make APL fit into the ascii terminal world. There is NO doubt in my mind that this seriously hampered APL's acceptance as a popular language in the 70's and 80's. > I beleive IBM did in the old days, or was it only caps?, and DEC and Data Decals (to tell you where the right parenthesis key is when it is not where you expect it to be... Duuhh) did NOT solve the problems of: - Using ascii-only terminals - transmitting APL programs across ascii-based networks. > Because knowledge of APL characters is only relevant to programmers, this Not so. See above. It affects users and system administrators. Ever triedto explain to someone back in the dark ages why your APL system couldn't print a report with someone's name in Upper Case and Lower Case because APL only had upper case and underbarred characters? > Proof #2, by counter example, i.e. J > Could you say e.g.: "Let's give APL common ASCII-characters and it would > become as popular as Yahoo?" Read my message again. I was discussing history. What DID and DID NOT happen. I am not attempting to peddle APL characters in the 90's. It's too late for that. Marketing and trendiness have taken over from technical superiority. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-28 0:00 ` Robert Bernecky @ 1997-10-28 0:00 ` James L. Ryan 1997-10-29 0:00 ` Robert Bernecky 0 siblings, 1 reply; 147+ messages in thread From: James L. Ryan @ 1997-10-28 0:00 UTC (permalink / raw) In article <34565F22.5B66C13E@acm.org>, Robert Bernecky <bernecky@acm.org> wrote: [snip] > > I am talking about history and what DID happen. There was no serious > attempt by any vendor to make APL fit into the ascii terminal world. > There is NO doubt in my mind that this seriously hampered APL's acceptance > as a popular language in the 70's and 80's. In the early seventies Burroughs APL had a "keyword" mode which was intended to make APL somewhat accessible from an ASCII terminal. When keywords were enabled APL letters mapped into ASCII lowercase and APL underscored letters mapped into ASCII uppercase. APL's special characters were represented by mnemonics embraced by less-than and greater-than symbols. Admittedly this was not intended to be a substitute for an APL terminal, but was intended to allow "emergency" access to APL from a non-APL terminal. With keywords on, and from an ASCII terminal, a line of APL might have looked as follows: average<is>(+/data)<div><rho>data<is><quad> Burroughs also contracted, in the early seventies, with Memorex to build a small number of terminals with 188 printing glyphs, 94 for ASCII and 94 for APL. These terminals could be either hard switched or soft switched between the character sets. The encodation of the characters was based upon the so-called APL/ASCII Typewriter Pairing overlay standard which was agreed upon at the Atlanta APL conference. The inclusion of the dual character set slowed the performance by a factor of two, but these terminals were still faster than the then only alternative, the 2741 and friends "golf-ball" terminals. Even though Burroughs attempted to sell these Memorex dual character set terminals, the market didn't seem interested. [snip] > > Not so. See above. It affects users and system administrators. Ever triedto > explain to someone back in the dark ages why your APL system couldn't print > a report with someone's name in Upper Case and Lower Case because APL > only had upper case and underbarred characters? Actually the ability to have computer output with both upper and lower case didn't come about until the early sixties. The computers I programmed in the late fifties used six bits instead of eight bits to represent characters. Rather amusingly, the first computer I programmed had 32 bit words which hosted five six-bit characters per word. You had the uppercase alphabet, the numerals, and a variety of punctuation characters. [snip] > -- James L. Ryan -- bosworth@waterw.com ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-28 0:00 ` James L. Ryan @ 1997-10-29 0:00 ` Robert Bernecky [not found] ` <bosworth-2910972044300001@access59.accsyst.com> 0 siblings, 1 reply; 147+ messages in thread From: Robert Bernecky @ 1997-10-29 0:00 UTC (permalink / raw) To: James L. Ryan James L. Ryan wrote: > In article <34565F22.5B66C13E@acm.org>, Robert Bernecky <bernecky@acm.org> > wrote: > In the early seventies Burroughs APL had a "keyword" mode which was > intended to make APL somewhat accessible from an ASCII terminal. When > keywords were enabled APL letters mapped into ASCII lowercase and APL The word "somewhat" is indeed true. I may have invented the first ascii/apltranslator when I wrote Teletype support into SHARP APL in 1971 or 1972. I included a translation function that took two character matrices [glyphs and their text representation] and used that to translate text one way to the other. You reversed translation direction by switching the matrix arguments. Similar in spirit to Weigang's APLASCII mapping arrays, but more primitive. > underscored letters mapped into ASCII uppercase. APL's special characters > were represented by mnemonics embraced by less-than and greater-than > symbols. Admittedly this was not intended to be a substitute for an APL > terminal, but was intended to allow "emergency" access to APL from a > non-APL terminal. With keywords on, and from an ASCII terminal, a line of > APL might have looked as follows: ALL of the keyword schemes I saw (ALL of which differed from vendor to vendor and even within a single vendor's products) had a number of bad characteristics, such as: - incorrect caret placement on error display - difficulties with escape characters - little (no) attention paid to user-centered design, to make the thing inviting to use. As you point out, Jim, they were strictly "Emergency use only" interfaces. > Burroughs also contracted, in the early seventies, with Memorex to build a > small number of terminals with 188 printing glyphs, 94 for ASCII and 94 > for APL. These terminals could be either hard switched or soft switched Yes, indeed. The mighty MRX1240, with an 18 inch long ribbon cartridge thatcost a bundle, inability to see what you were typing or where the cursor was, and a MTBF of a few hours. > friends "golf-ball" terminals. Even though Burroughs attempted to sell > these Memorex dual character set terminals, the market didn't seem > interested. Probably the market asked the suckers (like us) who actually bought oneor two of them first. > Actually the ability to have computer output with both upper and lower > case didn't come about until the early sixties. The computers I programmed Well before the inception of the APL\360 project. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <bosworth-2910972044300001@access59.accsyst.com>]
* Re: Programming language vote - results [not found] ` <bosworth-2910972044300001@access59.accsyst.com> @ 1997-10-30 0:00 ` Robert Bernecky 1997-10-30 0:00 ` James L. Ryan 0 siblings, 1 reply; 147+ messages in thread From: Robert Bernecky @ 1997-10-30 0:00 UTC (permalink / raw) To: James L. Ryan James L. Ryan wrote: > In article <34576752.11BAACA1@acm.org>, Robert Bernecky <bernecky@acm.org> > wrote: > > [snip] > > > ALL of the keyword schemes I saw (ALL of which differed from > > vendor to vendor and even within a single vendor's products) had a > > number of bad characteristics, such as: > [snip] > > I can't comment on keyword schemes other than the one we implemented at > Burroughs, but we did have correct caret placement on errors. (As an I don't think I ever saw this in action. Sorry. > I'm not sure what you mean by "difficulties with escape characters" or Ability to read a text matrix containing one or more escape characters, whencolumns were supposed to line up. Your scheme (adding blank columns) could make a function display REALLY wide. The key here is that > "user-centered design." I have no recollection of an escape character Check http://www.ibm.com/ucd for a bit of stuff on user-centered orhuman-centered design. Also, look at SIGCHI (Human-Computer Interaction) Proceedings going back 10 years or so. UCD's fundamental precepts include stuff like: you never design something right the first time, the designer is NOT the person who should make decisions about the usability of a design [the designer is blind to its faults and will often blame the user instead of the design. If you ever do usability testing (I mean formal testing, not shipping a beta off to a few people), you'll quickly find the major holes in your design, when you see 4 out of 5 users making EXACTLY the same errors.], use of ergonomic measures such as Fitt's Law [Failure to observe this is why the Windows up/down scrollbutton placement is so frustrating.] and so on. I'd like to see someone fund an APL usability study. I'll bet the language design would dramatically improve within weeks. > problem when using an ASCII terminal with Burroughs APL. Given that at the You are not a normal user, being bright, totally familiar with the product,and [bad bad bad] a designer of it. > time APL was accessed solely through hard-copy terminals, I feel that the > input and editing conventions implemented by Burroughs were a cut above > those implemented with APL/360. And given that the use of a special Your crew did some very nice design work. Generally, elegant and clean, well-thought-out ideas. Of course, with regard to your comment on Burroughs APL vs APL\360: "One of the problems of being a pioneer is that you always make mistakes, and I never, never want to be a pioneeer. It's always best to come second when you can look at the mistakes the pioneers made." Seymour Cray, LLNL CRAY-1 Introduction Lecture (1976). Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-30 0:00 ` Robert Bernecky @ 1997-10-30 0:00 ` James L. Ryan 1997-10-31 0:00 ` Robert Bernecky 0 siblings, 1 reply; 147+ messages in thread From: James L. Ryan @ 1997-10-30 0:00 UTC (permalink / raw) In article <3458D7A4.A64A0D8F@acm.org>, Robert Bernecky <bernecky@acm.org> wrote: [snip] > Ability to read a text matrix containing one or more escape characters, > whencolumns were supposed to line up. Your scheme (adding blank columns) > could make a function display REALLY wide. The key here is that > [snip] Bob, I'm a bit confused. The column widening used in Burroughs APL/700 to accomodate keywords had nothing to do with function display unless the matrix being displayed contained, say, the canonical representation of a function. As for the direct display of functions, APL/700, as did all APLs at the time, reformatted the functions into a canonical form in which redundant blanks were removed. This removal held whether keywords were enabled or not. As a now somewhat humorous aside, APL/700, when displaying a function, removed all redundant parentheses. To some this was blasphemy and to others this was a desirable feature. (This removal was a byproduct of the line image being reconstructed from the prefix Polish representation to which all source lines were converted to immediately prior to initial execution--the redundant parentheses would appear in a function image for those lines not yet executed.) Jim -- James L. Ryan -- bosworth@waterw.com ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-30 0:00 ` James L. Ryan @ 1997-10-31 0:00 ` Robert Bernecky 1997-10-31 0:00 ` James L. Ryan 0 siblings, 1 reply; 147+ messages in thread From: Robert Bernecky @ 1997-10-31 0:00 UTC (permalink / raw) To: James L. Ryan James L. Ryan wrote: > In article <3458D7A4.A64A0D8F@acm.org>, Robert Bernecky <bernecky@acm.org> > wrote: > > [snip] > > > Ability to read a text matrix containing one or more escape characters, > > whencolumns were supposed to line up. Your scheme (adding blank columns) > > could make a function display REALLY wide. The key here is that > > I'm a bit confused. The column widening used in Burroughs APL/700 to > accomodate keywords had nothing to do with function display unless the > matrix being displayed contained, say, the canonical representation of a I'm thinking of how one might have made a user-friendly matrix editor. > enabled or not. As a now somewhat humorous aside, APL/700, when displaying > a function, removed all redundant parentheses. To some this was blasphemy > and to others this was a desirable feature. (This removal was a byproduct Redundancy is in the eyes of the redunder. I think that keeping the text as entered is a much better idea, having suffered from the disappearing white space school of design. Keeping parens and white space allows the programmer to lay things out in a manner that may enhance clarity of structure to a reader, without making any difference (aside from space and cpu cycles, which don't appear to matter to people anymore... 8^}) to the computer. Bob ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-31 0:00 ` Robert Bernecky @ 1997-10-31 0:00 ` James L. Ryan 0 siblings, 0 replies; 147+ messages in thread From: James L. Ryan @ 1997-10-31 0:00 UTC (permalink / raw) In article <3459FAF1.CA68D6CB@acm.org>, Robert Bernecky <bernecky@acm.org> wrote: [snip] > > Redundancy is in the eyes of the redunder. I think that keeping the > text as entered is a much better idea, having suffered from the disappearing > white space school of design. Keeping parens and white space allows the > programmer to lay things out in a manner that may enhance clarity of > structure to a reader, without making any difference (aside from space and > cpu cycles, which don't appear to matter to people anymore... 8^}) > to the computer. Dyalog APL does remove redundant white spaces within the APL code but does preserve comment positioning, and, as a default, preserves leading indentation. A user preference provides for "AutoFormatting" of functions. With this facility enabled, the indentation preceding each line is automatically determined. Such indentation facilitates the reading of programs as the beginning and ending of the control structures are then easily paired. I've found that, with autoformatting enabled, I tend to not miss the ability to include arbitrary white space within my APL code. As an aside, I have wished, on a number of occasions, for the capability of breaking (with user selected break points) a long line of APL code into multiple lines of display. -- James L. Ryan -- bosworth@waterw.com ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-25 0:00 ` Kaz @ 1997-10-29 0:00 ` Jack Rudd 1 sibling, 0 replies; 147+ messages in thread From: Jack Rudd @ 1997-10-29 0:00 UTC (permalink / raw) Alan E & Carmel J Brain wrote: > > Jack Rudd wrote: > > > > Alan E & Carmel J Brain wrote: > > > > > > ... Now I think that APL has a place, > > > but only in small, one-use throw-aways, ---->8------ > > > I'm an algorithm developer. The greatest value of APL for me is > > in rapid prototyping. > > Concur completely, an excellent example of 1-use throw-away is when > you're developing and testing an algorithm! APL is one heck of a good > rapid prototyping language. In fact, for algorithm design, I can't think > of one better. > I very seldom throw away a prototyped algorithm. Write enough of them (I'm coming up on 30 years of this activity), and one can prototype subsystems, then whole systems. My APL96 paper describes one of these... an APL2 prototype of a "hard real-time" system. In general, I advocate translating a prototyped system from APL to another language just prior to delivery to a customer...who, when he screws it up, can't then blame his problems on APL! Jack Rudd ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-20 0:00 ` Alan E & Carmel J Brain ` (3 preceding siblings ...) 1997-10-23 0:00 ` Programming language vote - results Jack Rudd @ 1997-10-25 0:00 ` Peter Seebach 1997-11-18 0:00 ` Ingemar Ragnemalm 4 siblings, 1 reply; 147+ messages in thread From: Peter Seebach @ 1997-10-25 0:00 UTC (permalink / raw) In article <344BCED0.2D51@dynamite.com.au>, Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: >Hence my preference for Ada. When listening to C weenies - er - >enthusiasts talking about how their code is so tight, so efficient, and >above all so impenetrable that it's obviously superior to another >solution (in Ada so clear that "Any Fool could have written that"), I >have to take a dried-frog pill and count to 10. Can you honestly point to anyone claiming that "impenetrable" is a sign of superiority out of the IOCCC? Efficient is good. Tight can be good. Impenetrable is generally not good. I disagree with at least the implications of your conclusion. Writing, on purpose, impenetrable, bad, inefficient, and ugly code is one of the best ways to comprehend good code better. It's all well and good to say "look, here's a good way to do this". It's just as good to say "and look, here's a bad way". You can't understand fully what makes good code good without understanding just as fully what makes bad code bad. -s -- seebs@plethora.net -- Speaking for myself. No spam please. Copyright 1997. All rights reserved. This was not written by my cat. C/Unix wizard - send mail for help! --- http://www.plethora.net/~seebs http://www.plethora.net/ - More Net, Less Spam! ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-25 0:00 ` Peter Seebach @ 1997-11-18 0:00 ` Ingemar Ragnemalm 1997-11-18 0:00 ` firewind ` (4 more replies) 0 siblings, 5 replies; 147+ messages in thread From: Ingemar Ragnemalm @ 1997-11-18 0:00 UTC (permalink / raw) Peter Seebach wrote: > > In article <344BCED0.2D51@dynamite.com.au>, > Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: > >Hence my preference for Ada. When listening to C weenies - er - > >enthusiasts talking about how their code is so tight, so efficient, and > >above all so impenetrable that it's obviously superior to another > >solution (in Ada so clear that "Any Fool could have written that"), I > >have to take a dried-frog pill and count to 10. > > Can you honestly point to anyone claiming that "impenetrable" is a > sign of superiority out of the IOCCC? There are plenty of people who use C since it is "cool", but just can't say what is so cool with it. It is cool because Mom can't understand it. No, they won't say that. You can identify that kind of people by the lack of comments in the code. They *want* it that way - and they are many! > Efficient is good. Tight can be good. Impenetrable is generally not > good. When "efficient" and "tight" means as few keystrokes as possible, it isn't good. Efficient C code usually means that you take responsabilities that the optimizer should really do for you, and do that through questionable backdoors in the language. Case switches jumping into while loops is one example. > I disagree with at least the implications of your conclusion. Writing, > on purpose, impenetrable, bad, inefficient, and ugly code is one of the > best ways to comprehend good code better. It's all well and good to say > "look, here's a good way to do this". It's just as good to say "and look, > here's a bad way". > You can't understand fully what makes good code good without understanding > just as fully what makes bad code bad. When you show the bad way to those kids, they think it is WAAAY cool! They will use any stinking obscure construction just because "it is valid C code". Simple example from real life: if (call_this() || call_that()); Valid, yes. Better than if (!call_this()) call_that(); or more clear forms in other languages? Some people actually think so. /Ingemar ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Ingemar Ragnemalm @ 1997-11-18 0:00 ` firewind 1997-11-18 0:00 ` Kevin Swan ` (5 more replies) 1997-11-18 0:00 ` Kevin Swan ` (3 subsequent siblings) 4 siblings, 6 replies; 147+ messages in thread From: firewind @ 1997-11-18 0:00 UTC (permalink / raw) Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote: > Peter Seebach wrote: > > Can you honestly point to anyone claiming that "impenetrable" is a > > sign of superiority out of the IOCCC? > There are plenty of people who use C since it is "cool", but just can't > say what is so cool with it. It is cool because Mom can't understand it. > No, they won't say that. So, you insult a great many professional C programmers, and hobbyists, et cetra by comparing them to an adolescent who just follows the crowd? The crowd is gaping at OOP at the moment. C is not OOP. > You can identify that kind of people by the > lack of comments in the code. They *want* it that way - and they are > many! I very seldom comment my code at the first writing. I prefer to just code and get it done, then go back later and add comments, but -only- to code which is not easily understood. > > Efficient is good. Tight can be good. Impenetrable is generally not > > good. > When "efficient" and "tight" means as few keystrokes as possible, it > isn't good. Why not? You are associating 'few keystrokes' with 'unintelligible' and 'brokenly using bad self-optimization techniques' which is not correct. > Efficient C code usually means that you take > responsabilities > that the optimizer should really do for you, and do that through > questionable backdoors in the language. Case switches jumping into > while loops is one example. 'Questionable backdoors'? Some might disagree. BTW, last time I checked, the C standard didn't garuntee there is an optimizer around to babysit you. > > I disagree with at least the implications of your conclusion. Writing, > > on purpose, impenetrable, bad, inefficient, and ugly code is one of the > > best ways to comprehend good code better. It's all well and good to say > > "look, here's a good way to do this". It's just as good to say "and look, > > here's a bad way". > > You can't understand fully what makes good code good without understanding > > just as fully what makes bad code bad. > When you show the bad way to those kids, they think it is WAAAY cool! > They will use any stinking obscure construction just because "it is > valid C code". Again this insulting analogy. > Simple example from real life: > if (call_this() || call_that()); > Valid, yes. Better than > if (!call_this()) call_that(); > or more clear forms in other languages? > Some people actually think so. I find myself using a construct like this a lot recently (snipped directly from code I'm working on right now): if(!to && !(to = malloc(sizeof *to)))) return(NULL); For 'verbose' code this would be written: if(!to) { if(!to = malloc(sizeof *to)) { return(NULL); } } I find this unacceptable. The first form is understood well enough anyway: If 'to' is not valid and an attempt to make 'to' valid fails, return an error. The if(foo() || bar()) construct may seem obfuscated and weird to you, it is the way the logic of some people's minds work. To insult these people by comparing them to fickle adolescents is simply out of line. -- [- firewind -] [- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work) -] [- "You're just jealous because the voices talk to -me-." -] [- Have a good day, and enjoy your C. -] [- (on a crusade of grumpiness where grumpiness is due) -] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` firewind @ 1997-11-18 0:00 ` Kevin Swan 1997-11-19 0:00 ` Alan E & Carmel J Brain 1997-11-18 0:00 ` Larry Elmore ` (4 subsequent siblings) 5 siblings, 1 reply; 147+ messages in thread From: Kevin Swan @ 1997-11-18 0:00 UTC (permalink / raw) firewind (firewind@metroid.dyn.ml.org) wrote: : I very seldom comment my code at the first writing. I prefer to just code : and get it done, then go back later and add comments, but -only- to : code which is not easily understood. Heh, I take a somewhat opposite route. I comment before I code. :) Quite often, the first iteration of my programs look like this: FILE *fp; int count = 0; /* Open the file, test for errors. */ while (1) { /* Read a line, look for keyword. */ /* If found a keyword, print the line, otherwise increment count. */ /* If EOF hit, break out of loop. */ } /* Close file, print results to stdout. */ I then go back and fill in the code. I find this approach works quite well, and is very close to the top-down paradigm. Kev. -- Kevin Swan BCSH My university broke my email. If you want to email me, please send it to 013639s@dragon.acadiau.ca Acadia University How's my posting? Call 1-800-DEV-NULL ** Fatal Error [1]: 'Win95' virus detected on /dev/hda1; Formatting ... ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Kevin Swan @ 1997-11-19 0:00 ` Alan E & Carmel J Brain 0 siblings, 0 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-19 0:00 UTC (permalink / raw) Kevin Swan wrote: > > firewind (firewind@metroid.dyn.ml.org) wrote: > > : I very seldom comment my code at the first writing. I prefer to just code > : and get it done, then go back later and add comments, but -only- to > : code which is not easily understood. > > Heh, I take a somewhat opposite route. I comment before I code. I'd recommend this practice, regardless of the language you're doing it in. Of course, with a high-level language, Start the Ethernet Process Task becomes ETHERNET(START); and even a not-so-high-level language can have Ethernet->Start(); and you can just chop-and-change the comment. Well-written Ada, for example, is almost character-for-character identical with a good PDL. In fact, there's an IEEE standard on the use of Ada _AS_ a PDL. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` firewind 1997-11-18 0:00 ` Kevin Swan @ 1997-11-18 0:00 ` Larry Elmore 1997-11-20 0:00 ` firewind 1997-11-19 0:00 ` Mike Smith ` (3 subsequent siblings) 5 siblings, 1 reply; 147+ messages in thread From: Larry Elmore @ 1997-11-18 0:00 UTC (permalink / raw) firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... >I very seldom comment my code at the first writing. I prefer to just code >and get it done, then go back later and add comments, but -only- to >code which is not easily understood. Personally, I find it much easier to write the comments describing what each procedure/function does _first_ (after doing as much design work as I can force myself to do -- I don't _like_ doing it, but it sure beats bug-hunting), with stubs, _then_ adding in the code and whatever few comments are needed to describe what the code is doing at any point. Leaving all the commenting to the end makes it seem a bigger, more burdensome job, especially since the program is already done. I suspect this is one reason why so many programs out there are so poorly commented... >I find myself using a construct like this a lot recently (snipped directly >from code I'm working on right now): > >if(!to && !(to = malloc(sizeof *to)))) return(NULL); I _hope_ this isn't really snipped directly from your program, since the compiler will choke on the parentheses... ;) Larry ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Larry Elmore @ 1997-11-20 0:00 ` firewind 0 siblings, 0 replies; 147+ messages in thread From: firewind @ 1997-11-20 0:00 UTC (permalink / raw) Larry Elmore <ljelmore@montana.campus.mci.net> wrote: > firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... > >I very seldom comment my code at the first writing. I prefer to just code > >and get it done, then go back later and add comments, but -only- to > >code which is not easily understood. > Personally, I find it much easier to write the comments describing what each > procedure/function does _first_ (after doing as much design work as I can > force myself to do -- I don't _like_ doing it, but it sure beats > bug-hunting), with stubs, _then_ adding in the code and whatever few > comments are needed to describe what the code is doing at any point. Leaving > all the commenting to the end makes it seem a bigger, more burdensome job, > especially since the program is already done. I suspect this is one reason > why so many programs out there are so poorly commented... Well, I document my interface first, on paper, (actually, with 'vi' :) then I code the interface, then I comment anything hard to understand -within- the individual functions. (If I know at the time that what I'm coding is confusing, even to myself, I'll comment as I code... this is comparitively rare, however.) > >I find myself using a construct like this a lot recently (snipped directly > >from code I'm working on right now): > > > >if(!to && !(to = malloc(sizeof *to)))) return(NULL); ^ one too many > I _hope_ this isn't really snipped directly from your program, since the > compiler will choke on the parentheses... ;) Whoops, they are indeed unbalanced! Sorry. :) -- [- firewind -] [- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work) -] [- "You're just jealous because the voices talk to -me-." -] [- Have a good day, and enjoy your C. -] [- (on a crusade of grumpiness where grumpiness is due) -] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` firewind 1997-11-18 0:00 ` Kevin Swan 1997-11-18 0:00 ` Larry Elmore @ 1997-11-19 0:00 ` Mike Smith 1997-11-19 0:00 ` Matt 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Coding for Obscurity Alan E & Carmel J Brain ` (2 subsequent siblings) 5 siblings, 2 replies; 147+ messages in thread From: Mike Smith @ 1997-11-19 0:00 UTC (permalink / raw) firewind <firewind@metroid.dyn.ml.org> wrote in article <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... > Again this insulting analogy. > > > Simple example from real life: > > > if (call_this() || call_that()); > > > Valid, yes. Better than > > > if (!call_this()) call_that(); > > > or more clear forms in other languages? > > Some people actually think so. > > I find myself using a construct like this a lot recently (snipped directly > from code I'm working on right now): > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > For 'verbose' code this would be written: > > if(!to) { > if(!to = malloc(sizeof *to)) { > return(NULL); > } > } > Yeah, and what's wrong with that? Looks good to me - better than the logical expression. And in the first case, if (!call_this) call_that(); is also the better form. A good programmer writes code that even less-skilled programmers can easily read and maintain. Unless, of course, the code you write will never need to be maintained or updated, in which case it is probably of little consequence in the real world. > some people's minds work. To insult these people by comparing them to > fickle adolescents is simply out of line. > Okay, how about comparing them to snooty elitist "artists" or "craftsmen" that are more interested in form than function? (Function being defined by a whole host of things other than the actual operation of the program itself, like robustness, readability, maintainability, portability, etc.) --Mike Smith ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-19 0:00 ` Mike Smith @ 1997-11-19 0:00 ` Matt 1997-11-20 0:00 ` firewind 1 sibling, 0 replies; 147+ messages in thread From: Matt @ 1997-11-19 0:00 UTC (permalink / raw) To: Mike Smith <snip> > Yeah, and what's wrong with that? Looks good to me - better than the > logical expression. And in the first case, > > if (!call_this) call_that(); ^ Uh, Mike. | A good programmer remembers to Call the function! ;-) ---- sorry, I couldn't resist!!! Matt ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-19 0:00 ` Mike Smith 1997-11-19 0:00 ` Matt @ 1997-11-20 0:00 ` firewind [not found] ` <3474C71B.536B12F6@cgocable.net> 1997-11-23 0:00 ` Lawrence Kirby 1 sibling, 2 replies; 147+ messages in thread From: firewind @ 1997-11-20 0:00 UTC (permalink / raw) Mike Smith <kld_msmith@earthlink.nospam.net> wrote: > firewind <firewind@metroid.dyn.ml.org> wrote in article > <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... > > I find myself using a construct like this a lot recently (snipped directly > > from code I'm working on right now): > > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > For 'verbose' code this would be written: > > > > if(!to) { > > if(!to = malloc(sizeof *to)) { > > return(NULL); > > } > > } > > > Yeah, and what's wrong with that? Nothing, obviously. > Looks good to me - better than the > logical expression. This is purely your opinion. Either are correct, and either can be understood with little or no effort. (BTW, it's -still- a logical expression; it's just two now.) > And in the first case, > if (!call_this) call_that(); > is also the better form. Incorrect. It is the form that conforms more to your way of thinking. > A good programmer writes code that even > less-skilled programmers can easily read and maintain. I hope even less-skilled programmers can understand the boolean operators. > Unless, of course, > the code you write will never need to be maintained or updated, in which > case it is probably of little consequence in the real world. > > some people's minds work. To insult these people by comparing them to > > fickle adolescents is simply out of line. > Okay, how about comparing them to snooty elitist "artists" or "craftsmen" > that are more interested in form than function? Someone more interested in 'form' would write more 'pretty looking' constructs, would they not? I am still insulted by your statement. I code the way I code. My code works. I frankly don't care whether or not you think my style is 'pretty.' Anything above 'it works' is nothing more than a matter of opinion. Period. I find it pretty arrogant for you to think your way is the One True Style of Coding, and that anyone who dares do differently is a 'snob' or an 'adolescent' or an 'elitist.' -- [- firewind -] [- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work) -] [- "You're just jealous because the voices talk to -me-." -] [- Have a good day, and enjoy your C. -] [- (on a crusade of grumpiness where grumpiness is due) -] ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <3474C71B.536B12F6@cgocable.net>]
* Re: Programming language vote - results [not found] ` <3474C71B.536B12F6@cgocable.net> @ 1997-11-21 0:00 ` CVigue 0 siblings, 0 replies; 147+ messages in thread From: CVigue @ 1997-11-21 0:00 UTC (permalink / raw) In the given example the shorter version is more obvious and easier to understand while the longer example is IMO a waste of time and effort. I think leaving good comments at critical points in the code is more helpful than trying to predict the next programmers preferences. I wonder if anyone here REALLY finds the short version difficult, or if they are trying to help the mythical 'other guy' who can't understand it, or perhaps just want a discussion of style. Charlie V. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-20 0:00 ` firewind [not found] ` <3474C71B.536B12F6@cgocable.net> @ 1997-11-23 0:00 ` Lawrence Kirby 1997-11-24 0:00 ` FRS DES 1 sibling, 1 reply; 147+ messages in thread From: Lawrence Kirby @ 1997-11-23 0:00 UTC (permalink / raw) In article <6501ih$r1a@dfw-ixnews10.ix.netcom.com> firewind@metroid.dyn.ml.org "firewind" writes: >Mike Smith <kld_msmith@earthlink.nospam.net> wrote: >> firewind <firewind@metroid.dyn.ml.org> wrote in article >> <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... >> > I find myself using a construct like this a lot recently (snipped directly >> > from code I'm working on right now): >> > >> > if(!to && !(to = malloc(sizeof *to)))) return(NULL); >> > >> > For 'verbose' code this would be written: >> > >> > if(!to) { >> > if(!to = malloc(sizeof *to)) { >> > return(NULL); >> > } >> > } >> > > >> Yeah, and what's wrong with that? > >Nothing, obviously. The second form is invalid, it is interpreted the same as: if((!to) = malloc(sizeof *to)) { What is required at the very least is: if(!(to = malloc(sizeof *to))) { -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-23 0:00 ` Lawrence Kirby @ 1997-11-24 0:00 ` FRS DES 0 siblings, 0 replies; 147+ messages in thread From: FRS DES @ 1997-11-24 0:00 UTC (permalink / raw) In article <880301061snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes: > The second form is invalid, it is interpreted the same as: >if((!to) = malloc(sizeof *to)) { What is required at the very least is: >if(!(to = malloc(sizeof *to))) { This thread no longer seems to have anything to do withg APL -- Please remove comp.lang.apl from the list of newsgroups, or start a new thread. -David E. Siegel Software Developer, LEX2000, Inc (Formerly Financial Reporting Software, or FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-18 0:00 ` firewind ` (2 preceding siblings ...) 1997-11-19 0:00 ` Mike Smith @ 1997-11-20 0:00 ` Alan E & Carmel J Brain 1997-11-20 0:00 ` Stephan Wilms 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Programming language vote - results Andy Knight 1997-11-20 0:00 ` Terry Richards 5 siblings, 2 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-20 0:00 UTC (permalink / raw) firewind wrote: > I find myself using a construct like this a lot recently (snipped directly > from code I'm working on right now): > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > For 'verbose' code this would be written: > > if(!to) { > if(!to = malloc(sizeof *to)) { > return(NULL); > } > } > > I find this unacceptable. The first form is understood well enough anyway > The > > if(foo() || bar()) > > construct may seem obfuscated and weird to you, it is the way the logic of > some people's minds work. No further evidence, I rest my case. Would anyone in comp.lang.c like to comment? -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Coding for Obscurity Alan E & Carmel J Brain @ 1997-11-20 0:00 ` Stephan Wilms 1997-11-21 0:00 ` Jos A. Horsmeier ` (3 more replies) 1997-11-20 0:00 ` firewind 1 sibling, 4 replies; 147+ messages in thread From: Stephan Wilms @ 1997-11-20 0:00 UTC (permalink / raw) Alan E & Carmel J Brain wrote: > > firewind wrote: > > > I find myself using a construct like this a lot recently (snipped directly > > from code I'm working on right now): > > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > The > > if(foo() || bar()) > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > some people's minds work. > > No further evidence, I rest my case. > > Would anyone in comp.lang.c like to comment? Yes, I'll volunteer a little comment: code like that has a lot of disadvantages: it is obfuscated (it's only the author wh thinks that the code is readable) and it's hard to debug and maintain. It sure wouldn't pass through my code inspection. To explain: readability of code is not targeted at the author of the code or maybe his office pal, it is targeted at someone having to read and understand a whole big package of source code, to make some important modification or to find a bug a year after the software has been written and archived. The author might not even be available at this moment. Even the smallest effort helps a lot. In detail: I would reqrite the first example like this: /* Sensible comment about what get's allocated. */ if ( to == NULL ) { to = malloc( sizeof *to); if ( to == NULL ) return NULL; } Stephan (initiator of the campaign against grumpiness in c.l.c) ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Stephan Wilms @ 1997-11-21 0:00 ` Jos A. Horsmeier 1997-11-23 0:00 ` Al Christians ` (2 subsequent siblings) 3 siblings, 0 replies; 147+ messages in thread From: Jos A. Horsmeier @ 1997-11-21 0:00 UTC (permalink / raw) Stephan Wilms wrote: > Alan E & Carmel J Brain wrote: > > firewind wrote: > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > > > The > > > if(foo() || bar()) > > > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > > some people's minds work. > > No further evidence, I rest my case. > > Would anyone in comp.lang.c like to comment? > Yes, I'll volunteer a little comment: code like that has a lot of > disadvantages: it is obfuscated (it's only the author wh thinks that > the code is readable) and it's hard to debug and maintain. It sure > wouldn't pass through my code inspection. > > To explain: readability of code is not targeted at the author of the > code or maybe his office pal, it is targeted at someone having to > read and understand a whole big package of source code, to make > some important modification or to find a bug a year after the software > has been written and archived. The author might not even be available > at this moment. Even the smallest effort helps a lot. > > In detail: I would reqrite the first example like this: > > /* Sensible comment about what get's allocated. */ > if ( to == NULL ) > { > to = malloc( sizeof *to); > if ( to == NULL ) return NULL; > } Although we're talking about style and taste here (which can't be discussed IMHO), I jumped into (another thread of) this discussion because I recognized the construct above. Something like 15 years ago our team went OO (and gaga too, but that's an entirely different story ;-) C++ was hardly concipiated yet, so we turned to SmallTalk and borrowed (read 'stole') some features from that language. We were still dealing with plain old C though ... We wanted to handle 'automatic or global' objects and 'dynamic objects' (just to borrow some terminology from C++) in C. Amongst other stuff we came up with the following macros: #define NEW(x) ((x) && !((x)->dyn= NULL) || ((x)= malloc(sizeof *(x))) && ((x)->dyn= (x))) #define OLD(x) free((x)->dyn) (I'm typing this from the top of my head, so be gentle with me here) An object was represented by a simple struct. One member of such a struct 'dyn' contained the address of the struct itself if it was allocated dynamically, otherwise it would contain a NULL pointer. Given those macros we were able to do things like: void foo() { obj_t x; obj_t* y= NULL; if (NEW(&x)) /* init x; */ if (NEW(y)) /* init *y */ /* do some useful stuff with x and y here */ OLD(&x); OLD(&y); } The NEW macro registered the fact that the memory of an object was already there if it were passed the address of an existing struct. The OLD macro would peek at the 'dyn' member and pass it to free (we were simply lucky that free(NULL) did what we wanted it to do in those days, but if you tell them youngsters that, they won't believe ya ;-) I'm the one to blame for those macros. I just finished some boring project using RPG (I guess it was RPG2, but I don't recall exactly) and I did like those tagged statements, i.e. foo && bar where 'bar' would only be executed if 'foo' were true (later RISC chips even implemented this nice little feature). Maybe my braincell was damaged by my former RPG experience, but I found (and still find) the logic behind this all quite readable. So you're at least partly right: 'it's the author who thinks that this is readable'. But the fun part of this all is, that our team found this construct (and the accompanying macros) quite readable too, I wasn't the only lunatic in town ... I agree that such a construct shouldn't be written down just to inflate your ego, but a carefully constructed (or should I say 'crafted') expression like this can be highly readable for those who are at least familiar with it. But this notion leads to the question -- how qualified should software maintaining people be? If they're overqualified (and this very suitable for the job), they don't want this type of job (and vice versa is true too). kind regards, Jos aka jos@and.nl ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Stephan Wilms 1997-11-21 0:00 ` Jos A. Horsmeier @ 1997-11-23 0:00 ` Al Christians 1997-11-23 0:00 ` Alex Krol 1997-11-24 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 147+ messages in thread From: Al Christians @ 1997-11-23 0:00 UTC (permalink / raw) Somebody wrote: >> From the new Subject: I assume you have drawn the conclusion that I >> code in the above manner (the first 'weird' if(), I don't use the >> second, but the point was that 'style imperialism' is stupid) to >> purposely obfuscate. Nothing can be further from the truth. >> >> Obfuscated code can be written in absolutely any language, by >> absolutely everyone. In a bad spot, a decidedly 'clean' >> coder can churn out a potful of spaghetti code. But if you are getting into C++, there's a clue on page 12 in the _Notes_to_the_Reader_ of Stroustrup's _The_C++_Programming_Language_ (3rd edition). "Million line C++ programs are not uncommon". This form of expression warns the reader right up front that non-avoidance of non-unconvoluted expression by non-eschewers of C++ is not dissimilarly not uncommon. Or as Marx said, "I can't say that I don't disagree with you." Al ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Stephan Wilms 1997-11-21 0:00 ` Jos A. Horsmeier 1997-11-23 0:00 ` Al Christians @ 1997-11-23 0:00 ` Alex Krol 1997-11-24 0:00 ` Jim Johnson 1997-11-24 0:00 ` Richard A. O'Keefe 3 siblings, 1 reply; 147+ messages in thread From: Alex Krol @ 1997-11-23 0:00 UTC (permalink / raw) Stephan Wilms wrote: > > Alan E & Carmel J Brain wrote: > > > > firewind wrote: > > > > > I find myself using a construct like this a lot recently (snipped directly > > > from code I'm working on right now): > > > > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > > > The > > > if(foo() || bar()) > > > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > > some people's minds work. > > > > No further evidence, I rest my case. > > > > Would anyone in comp.lang.c like to comment? > > Yes, I'll volunteer a little comment: code like that has a lot of > disadvantages: it is obfuscated (it's only the author wh thinks that > the code is readable) and it's hard to debug and maintain. It sure > wouldn't pass through my code inspection. > > To explain: readability of code is not targeted at the author of the > code or maybe his office pal, it is targeted at someone having to > read and understand a whole big package of source code, to make > some important modification or to find a bug a year after the software > has been written and archived. The author might not even be available > at this moment. Even the smallest effort helps a lot. > > In detail: I would reqrite the first example like this: > > /* Sensible comment about what get's allocated. */ > if ( to == NULL ) > { > to = malloc( sizeof *to); > if ( to == NULL ) return NULL; > } Of course, style matters are extremely personal, but, IMHO, there is nothing unreadable in the first example (except unmatched parenthesis :-)). I agree that readability of code is not targeted at the author himself, but must it be targeted at a newbie unfamiliar with C idiomas? Comments, though are advisable in any case. Regards, Alex Krol ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-23 0:00 ` Alex Krol @ 1997-11-24 0:00 ` Jim Johnson 1997-11-24 0:00 ` Mark Wilden 0 siblings, 1 reply; 147+ messages in thread From: Jim Johnson @ 1997-11-24 0:00 UTC (permalink / raw) > I agree that readability of code is not targeted > at the author himself, but must it be targeted at a newbie unfamiliar > with C idiomas? Yes, it must; because in most situations, that is who the maintenance programmers are. "unfamiliar with C idioms" could be any of us. There are so many ways to write C code, there is no way to predict which ones your audience will have used. (Personally, I never use ?: conditionals; I always have to think it through when I see them.) Jim Johnson Alex Krol <Alex_Krol@scitex.com> wrote in article <34788101.7367@scitex.com>... > Stephan Wilms wrote: > > > > Alan E & Carmel J Brain wrote: > > > > > > firewind wrote: > > > > > > > I find myself using a construct like this a lot recently (snipped directly > > > > from code I'm working on right now): > > > > > > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > > > > > The > > > > if(foo() || bar()) > > > > > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > > > some people's minds work. > > > > > > No further evidence, I rest my case. > > > > > > Would anyone in comp.lang.c like to comment? > > > > Yes, I'll volunteer a little comment: code like that has a lot of > > disadvantages: it is obfuscated (it's only the author wh thinks that > > the code is readable) and it's hard to debug and maintain. It sure > > wouldn't pass through my code inspection. > > > > To explain: readability of code is not targeted at the author of the > > code or maybe his office pal, it is targeted at someone having to > > read and understand a whole big package of source code, to make > > some important modification or to find a bug a year after the software > > has been written and archived. The author might not even be available > > at this moment. Even the smallest effort helps a lot. > > > > In detail: I would reqrite the first example like this: > > > > /* Sensible comment about what get's allocated. */ > > if ( to == NULL ) > > { > > to = malloc( sizeof *to); > > if ( to == NULL ) return NULL; > > } > > Of course, style matters are extremely personal, but, IMHO, > there is nothing unreadable in the first example (except unmatched > parenthesis :-)). I agree that readability of code is not targeted > at the author himself, but must it be targeted at a newbie unfamiliar > with C idiomas? Comments, though are advisable in any case. > > Regards, > Alex Krol > ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Jim Johnson @ 1997-11-24 0:00 ` Mark Wilden 1997-11-26 0:00 ` Robert S. White 0 siblings, 1 reply; 147+ messages in thread From: Mark Wilden @ 1997-11-24 0:00 UTC (permalink / raw) Jim Johnson wrote: > > > I agree that readability of code is not targeted > > at the author himself, but must it be targeted at a newbie unfamiliar > > with C idiomas? > > Yes, it must; because in most situations, that is who the maintenance > programmers are. If the only code newbies read is code directed toward newbies, then they'll remain newbies. A good programmer is someone who can read an unfamiliar idiom (if it is truly useful and not merely obscure), learn it and apply it. > "unfamiliar with C idioms" could be any of us. There are so many ways to > write C code, there is no way to predict which ones your audience will have > used. (Personally, I never use ?: conditionals; I always have to think it > through when I see them.) But ?: is not an idiom; it's a part of the language definition. I'll give you the benefit of the doubt and assume that when you think it through, you understand it. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Mark Wilden @ 1997-11-26 0:00 ` Robert S. White 1997-11-26 0:00 ` Miguel Carrasquer Vidal ` (3 more replies) 0 siblings, 4 replies; 147+ messages in thread From: Robert S. White @ 1997-11-26 0:00 UTC (permalink / raw) In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says... >But ?: is not an idiom; it's a part of the language definition. I'll >give you the benefit of the doubt and assume that when you think it >through, you understand it. I _understood_ it in 1983. But right now in thinking about it, I'll say that it would have been better from a code maintenance point of view, that K&R had never thought of it as a convenient typing shortcut. IMHO YMMV _____________________________________________________________________ Robert S. White -- An embedded systems software engineer e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Robert S. White @ 1997-11-26 0:00 ` Miguel Carrasquer Vidal 1997-12-01 0:00 ` ISONE 1997-12-01 0:00 ` ISONE 1997-11-26 0:00 ` Mark Wilden ` (2 subsequent siblings) 3 siblings, 2 replies; 147+ messages in thread From: Miguel Carrasquer Vidal @ 1997-11-26 0:00 UTC (permalink / raw) On 26 Nov 1997 00:37:28 GMT, nospam@somewhere.ia.us (Robert S. White) wrote: >In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says... > >>But ?: is not an idiom; it's a part of the language definition. I'll >>give you the benefit of the doubt and assume that when you think it >>through, you understand it. > > I _understood_ it in 1983. But right now in thinking about >it, I'll say that it would have been better from a code maintenance >point of view, that K&R had never thought of it as a convenient >typing shortcut. IMHO YMMV The idea of a conditinal expression was already in Algol, e.g. x := if i>0 then y else z; Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4 esac] := false, and allowed if then else and fi to be abbreviated to (, |, |, ), giving either: x := if i>0 then y else z fi; or x := ( i>0 | y | z ); In CPL and later BCPL the conditional expression was also abbreviated, as in: x := i>0 -> y , z; This was changed to x = i>0 ? y : z; in B, so the K in K&R you mention above is actually Ken Thompson. This syntax was maintained unaltered in C. == Miguel Carrasquer Vidal ~ ~ Amsterdam _____________ ~ ~ mcv@wxs.nl |_____________||| ========================== Ce .sig n'est pas une .cig ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Miguel Carrasquer Vidal @ 1997-12-01 0:00 ` ISONE 1997-12-01 0:00 ` ISONE 1 sibling, 0 replies; 147+ messages in thread From: ISONE @ 1997-12-01 0:00 UTC (permalink / raw) BLISS is similar. All valid blocks of code have value or evaluate to a value. x = if .y eq .z then .a else .b; is a valid statement... x now containing the value pointed to by b. (Assuming I remember the nuances of my BLISS syntax :) m.s.jessop > >Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4 >esac] := false, and allowed if then else and fi to be abbreviated to >(, |, |, ), giving either: > >x := if i>0 then y else z fi; > >or > >x := ( i>0 | y | z ); > >In CPL and later BCPL the conditional expression was also abbreviated, >as in: > >x := i>0 -> y , z; > >This was changed to > >x = i>0 ? y : z; > >in B, so the K in K&R you mention above is actually Ken Thompson. >This syntax was maintained unaltered in C. > > >== >Miguel Carrasquer Vidal ~ ~ >Amsterdam _____________ ~ ~ >mcv@wxs.nl |_____________||| > >========================== Ce .sig n'est pas une .cig ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Miguel Carrasquer Vidal 1997-12-01 0:00 ` ISONE @ 1997-12-01 0:00 ` ISONE 1 sibling, 0 replies; 147+ messages in thread From: ISONE @ 1997-12-01 0:00 UTC (permalink / raw) BLISS is similar. All valid blocks of code have value or evaluate to a value. x = if .y eq .z then .a else .b; is a valid statement... x now containing the value pointed to by b. (Assuming I remember the nuances of my BLISS syntax :) m.s.jessop > >Algol 68 extended this to case-expressions like b[case i in 6, 3 out 4 >esac] := false, and allowed if then else and fi to be abbreviated to >(, |, |, ), giving either: > >x := if i>0 then y else z fi; > >or > >x := ( i>0 | y | z ); > >In CPL and later BCPL the conditional expression was also abbreviated, >as in: > >x := i>0 -> y , z; > >This was changed to > >x = i>0 ? y : z; > >in B, so the K in K&R you mention above is actually Ken Thompson. >This syntax was maintained unaltered in C. > > >== >Miguel Carrasquer Vidal ~ ~ >Amsterdam _____________ ~ ~ >mcv@wxs.nl |_____________||| > >========================== Ce .sig n'est pas une .cig ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Robert S. White 1997-11-26 0:00 ` Miguel Carrasquer Vidal @ 1997-11-26 0:00 ` Mark Wilden 1997-11-26 0:00 ` Leon Jones 1997-11-27 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 147+ messages in thread From: Mark Wilden @ 1997-11-26 0:00 UTC (permalink / raw) Robert S. White wrote: > > In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says... > > >But ?: is not an idiom; it's a part of the language definition. I'll > >give you the benefit of the doubt and assume that when you think it > >through, you understand it. > > I _understood_ it in 1983. I was talking about understanding a line of code and you're talking about understanding a syntax element, but never mind. > But right now in thinking about > it, I'll say that it would have been better from a code maintenance > point of view, that K&R had never thought of it as a convenient > typing shortcut. IMHO YMMV I don't look at it like that at all. I certainly would never use it instead of an if-statement just to save some typing (in fact, I don't use it very often at all). C/C++ is naturally a terse language, however, and one of the advantages of terseness, used appropriately, is the ability to let the reader "chunk" in order to understand the code faster. Terseness also can have maintenance benefits, in reducing duplication. For example, here's a case where I used the conditional operator recently: EnableMenuItem(hGameMenu, ID_NEWLIFE, (CanBeReborn() ? MF_ENABLED : MF_GRAYED) | MF_BYCOMMAND); I think this is easier to read and maintain than either // redundant--bad for maintenance if (CanBeReborn()) EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_ENABLED | MF_BYCOMMAND); else EnableMenuItem(hGameMenu, ID_NEWLIFE, MF_GRAYED | MF_BYCOMMAND); or // wordy--takes longer to read and understand // reader may wonder if flag is used further down unsigned flag; if (CanBeReborn()) flag = MF_ENABLED; else flag = MF_GRAYED; EnableMenuItem(hGameMenu, ID_NEWLIFE, flag | MF_BYCOMMAND); ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Robert S. White 1997-11-26 0:00 ` Miguel Carrasquer Vidal 1997-11-26 0:00 ` Mark Wilden @ 1997-11-26 0:00 ` Leon Jones 1997-11-26 0:00 ` Lawrence Kirby 1997-11-26 0:00 ` Ron Natalie 1997-11-27 0:00 ` Richard A. O'Keefe 3 siblings, 2 replies; 147+ messages in thread From: Leon Jones @ 1997-11-26 0:00 UTC (permalink / raw) Robert S. White <nospam@somewhere.ia.us> wrote in article <65fr08$vtu$1@flood.weeg.uiowa.edu>... > In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says... > > >But ?: is not an idiom; it's a part of the language definition. I'll > >give you the benefit of the doubt and assume that when you think it > >through, you understand it. > > I _understood_ it in 1983. But right now in thinking about > it, I'll say that it would have been better from a code maintenance > point of view, that K&R had never thought of it as a convenient > typing shortcut. IMHO YMMV Couldn't agree more. Ternary operators are horrendous and I avoid them at all costs. I've been programming for years and I still have to study them closely before I understand exactly what they do. It is just not as natural a representation as if/else statements. Also it doesn't allow for indentation which is surely good programming technique in anyone's book?? Leon. <snip sig> ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Leon Jones @ 1997-11-26 0:00 ` Lawrence Kirby 1997-11-26 0:00 ` Ron Natalie 1 sibling, 0 replies; 147+ messages in thread From: Lawrence Kirby @ 1997-11-26 0:00 UTC (permalink / raw) In article <01bcfa5d$7aab9920$LocalHost@default> leon.jones@lineone.net "Leon Jones" writes: >Robert S. White <nospam@somewhere.ia.us> wrote in article ><65fr08$vtu$1@flood.weeg.uiowa.edu>... >> In article <3479F8FB.2D7F@mWilden.com>, Mark@mWilden.com says... >> >> >But ?: is not an idiom; it's a part of the language definition. I'll >> >give you the benefit of the doubt and assume that when you think it >> >through, you understand it. >> >> I _understood_ it in 1983. But right now in thinking about >> it, I'll say that it would have been better from a code maintenance >> point of view, that K&R had never thought of it as a convenient >> typing shortcut. IMHO YMMV I suppose it depends on what you are used to. I suspect that people with a functional language background would be right at home with it. >Couldn't agree more. Ternary operators are horrendous and I avoid them at >all costs. I've been programming for years and I still have to study them >closely before I understand exactly what they do. It is just not as >natural a representation as if/else statements. Also it doesn't allow for >indentation which is surely good programming technique in anyone's book?? This is perhaps the problem: people don't format it very well. However your statement that it doesn't allow for indentation is patently false. There are various ways to indent it for long expressions. My preferred method is for example: (control expression 1) ? (control expression 2) ? value expression 1 : value expression 2 : value expression 3 -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Leon Jones 1997-11-26 0:00 ` Lawrence Kirby @ 1997-11-26 0:00 ` Ron Natalie 1997-11-27 0:00 ` Joerg Rodemann 1 sibling, 1 reply; 147+ messages in thread From: Ron Natalie @ 1997-11-26 0:00 UTC (permalink / raw) Leon Jones wrote: > Ternary operators are horrendous and I avoid them at > all costs. I wouldn't say that. They are very useful. It's only when people don't use the result of the ternary expression, but rather rely on side effects that's egregious. Those are the cases that can have if/else directly subsituted for them with no change in meaning. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Ron Natalie @ 1997-11-27 0:00 ` Joerg Rodemann 0 siblings, 0 replies; 147+ messages in thread From: Joerg Rodemann @ 1997-11-27 0:00 UTC (permalink / raw) Ron Natalie (ron@sensor.com) wrote: > Leon Jones wrote: > > Ternary operators are horrendous and I avoid them at > > all costs. > I wouldn't say that. They are very useful. > It's only when people don't use the result of the > ternary expression, but rather rely on side effects > that's egregious. Well, maybe that is the point that disturbs me with the ? : expressions. One of the examples given in a former post made quite sense although I do not like these operators. Indeed, if used in a functional manner (no side effects) they seem to be more readable than alternativ constructions like "if ... else ...". Probably I saw to many occurences of these were everything was hidden behind side effects. Same is to be said about stand alone expressions like: a() || b(); Perhaps I developped kind of a distrust towards programmers and their concerns about readability. *sigh* Regards Joerg -- rodemann@mathematik.uni-ulm.de | Dipl.-Phys. Joerg S. Rodemann Phone: ++49-(0)711-5090670 | Flurstrasse 21, D-70372 Stuttgart, Germany -------------------------------+--------------------------------------------- rodemann@hlrs.de | University of Stuttgart, Computing Center Phone: ++49-(0)711-685-5815 | Visualization Department, Office: 0.304 Fax: ++49-(0)711-682-357 | Allmandring 30a, D-70550 Stuttgart, Germany ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-26 0:00 ` Robert S. White ` (2 preceding siblings ...) 1997-11-26 0:00 ` Leon Jones @ 1997-11-27 0:00 ` Richard A. O'Keefe 3 siblings, 0 replies; 147+ messages in thread From: Richard A. O'Keefe @ 1997-11-27 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1301 bytes --] nospam@somewhere.ia.us (Robert S. White) writes: > I _understood_ it in 1983. But right now in thinking about >it, I'll say that it would have been better from a code maintenance >point of view, that K&R had never thought of it as a convenient >typing shortcut. IMHO YMMV They didn't think of it, and it isn't a typing shortcut. Conditional expressions were, and remain, a common feature of many programming languages, going back to 1959. Perhaps K&R chose to retain them, given their conscious contrast with Multics, because they were aware of the horrible kluge PL/I (and Pascal) programmers used to emulate them: ord(x >= 0)*x + ord(not(x >= 0))*(-x) is a peculiarly horrible way to have to write if x >= 0 then x else -x fi. Don't you find something rather repulsive about having to use side effects just to select one of two values? Much the same argument was used to justify the absence of 'and then' and 'or else' from the original Pascal: they are "only convenient typing shortcuts for if statements". But they aren't, and the current Pascal standard includes them (spelled and_then and or_else, and still with the wrong precedence). -- John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL. Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Stephan Wilms ` (2 preceding siblings ...) 1997-11-23 0:00 ` Alex Krol @ 1997-11-24 0:00 ` Richard A. O'Keefe 1997-11-24 0:00 ` Matt 1997-11-24 0:00 ` Samuel T. Harris 3 siblings, 2 replies; 147+ messages in thread From: Richard A. O'Keefe @ 1997-11-24 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1492 bytes --] Stephan Wilms <Stephan.Wilms@CWA.de> writes: >In detail: I would reqrite the first example like this: > /* Sensible comment about what get's allocated. */ > if ( to == NULL ) > { > to = malloc( sizeof *to); > if ( to == NULL ) return NULL; > } I would be rather unhappy at _any_ of these being common in my C code. One thing I would very much like to have in C is a '* __nonnull__' form. One thing I love about LC-Lint is that it distinguishes between sometype *p; /* p should not be null */ sometype */*@null@*/ q; /* q may or may not be null */ The reason that I dislike the C fragment above is that when you are forced to do manual memory management, you have to be absolutely clear about who `owns' a dynamically allocated object and who doesn't. This fragment muddies that up. If you could specify in the interface that to _couldn't_ be NULL on entry, then you wouldn't have to patch around the problem at run time. By the way, I regard this as a defect in Ada as well. Ada was supposed to allow for garbage collection, but with the exception of a couple of recent Ada->JVM compilers, this hasn't happened. Since you _do_ have to do manual memory management in practice, it is a pity that the language doesn't provide more compile-time help for getting it right. Perhaps Ada 2007 could borrow a few ideas from LC-Lint. -- John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL. Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Richard A. O'Keefe @ 1997-11-24 0:00 ` Matt 1997-11-24 0:00 ` Ed Falis 1997-11-24 0:00 ` Samuel T. Harris 1 sibling, 1 reply; 147+ messages in thread From: Matt @ 1997-11-24 0:00 UTC (permalink / raw) To: Richard A. O'Keefe --snip-- > By the way, I regard this as a defect in Ada as well. Ada was supposed to > allow for garbage collection, but with the exception of a couple of recent > Ada->JVM compilers, this hasn't happened. Since you _do_ have to do manual > memory management in practice, it is a pity that the language doesn't provide > more compile-time help for getting it right. Perhaps Ada 2007 could borrow a > few ideas from LC-Lint. Ada does provide for garbage collection. It just doesn't mandate it. Requiring it would make the language almost useless in real-time systems and we would see many "We're-just-like-Ada-but-without-the-garbage-collection" languages pop up. I do like the idea of being able to specifying that a pointer can never be null. It sould be handy in many situations. Matt ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Matt @ 1997-11-24 0:00 ` Ed Falis 0 siblings, 0 replies; 147+ messages in thread From: Ed Falis @ 1997-11-24 0:00 UTC (permalink / raw) By the way, ObjectAda for Windows and UNIX does work with the Great Circle garbage collector from Geodesic Systems. - Ed Falis Aonix Matt wrote in message <3479310A.2082@itsnet.com>... >--snip-- >> By the way, I regard this as a defect in Ada as well. Ada was supposed to >> allow for garbage collection, but with the exception of a couple of recent >> Ada->JVM compilers, this hasn't happened. Since you _do_ have to do manual >> memory management in practice, it is a pity that the language doesn't provide >> more compile-time help for getting it right. Perhaps Ada 2007 could borrow a >> few ideas from LC-Lint. > >Ada does provide for garbage collection. It just doesn't mandate it. >Requiring it would make the language almost useless in real-time systems >and we would see many >"We're-just-like-Ada-but-without-the-garbage-collection" languages pop >up. > >I do like the idea of being able to specifying that a pointer can never >be null. It sould be handy in many situations. > >Matt ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Richard A. O'Keefe 1997-11-24 0:00 ` Matt @ 1997-11-24 0:00 ` Samuel T. Harris 1997-11-24 0:00 ` Jon S Anthony 1 sibling, 1 reply; 147+ messages in thread From: Samuel T. Harris @ 1997-11-24 0:00 UTC (permalink / raw) Richard A. O'Keefe wrote: > = > Stephan Wilms <Stephan.Wilms@CWA.de> writes: > >In detail: I would reqrite the first example like this: > = > > /* Sensible comment about what get's allocated. */ > > if ( to =3D=3D NULL ) > > { > > to =3D malloc( sizeof *to); > > if ( to =3D=3D NULL ) return NULL; > > } > = > I would be rather unhappy at _any_ of these being common in my C code. > One thing I would very much like to have in C is a '* __nonnull__' form= =2E > One thing I love about LC-Lint is that it distinguishes between > sometype *p; /* p should not be null */ > sometype */*@null@*/ q; /* q may or may not be null */ > = > The reason that I dislike the C fragment above is that when you are for= ced > to do manual memory management, you have to be absolutely clear about w= ho > `owns' a dynamically allocated object and who doesn't. This fragment > muddies that up. If you could specify in the interface that to _couldn= 't_ > be NULL on entry, then you wouldn't have to patch around the problem at= > run time. > = > By the way, I regard this as a defect in Ada as well. Ada was supposed= to > allow for garbage collection, but with the exception of a couple of rec= ent > Ada->JVM compilers, this hasn't happened. Since you _do_ have to do ma= nual > memory management in practice, it is a pity that the language doesn't p= rovide > more compile-time help for getting it right. Perhaps Ada 2007 could bo= rrow a > few ideas from LC-Lint. Yeah, I agree that Ada 83 was very weak in "helping" with memory management. And Ada 95 is somewhat better in this regards (i.e. providing access parameters eliminates many needs for access types). However, Ada 95 does provide the storage_pool scheme where I can build whatever memory management system I need to include whatever elaborate facilities I desire. I'm anxious to see what storage_pools become available as reuse components. Indeed, I've used simple storage_pools simply to guarantee certain pointers to heterogenous types are stored in consecutive memory. I can then send that memory block across an interface and eliminate all the normal code associate with staging the values into a message record for sending and extracting the values from a received message record. > -- > John =C6neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL. > Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok -- = Samuel T. Harris, Senior Engineer Hughes Training, Inc. - Houston Operations 2224 Bay Area Blvd. Houston, TX 77058-2099 "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Samuel T. Harris @ 1997-11-24 0:00 ` Jon S Anthony 1997-11-25 0:00 ` Samuel T. Harris 0 siblings, 1 reply; 147+ messages in thread From: Jon S Anthony @ 1997-11-24 0:00 UTC (permalink / raw) "Samuel T. Harris" <s_harris@hso.link.com> writes: > reuse components. Indeed, I've used simple storage_pools simply to > guarantee certain pointers to heterogenous types are stored in > consecutive memory. I can then send that memory block across an > interface and eliminate all the normal code associate with staging > the values into a message record for sending and extracting the > values from a received message record. Now that is quite nice and clever. -- Jon Anthony Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 "Nightmares - Ha! The way my life's been going lately, Who'd notice?" -- Londo Mollari ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-24 0:00 ` Jon S Anthony @ 1997-11-25 0:00 ` Samuel T. Harris 0 siblings, 0 replies; 147+ messages in thread From: Samuel T. Harris @ 1997-11-25 0:00 UTC (permalink / raw) Jon S Anthony wrote: > > "Samuel T. Harris" <s_harris@hso.link.com> writes: > > > reuse components. Indeed, I've used simple storage_pools simply to > > guarantee certain pointers to heterogenous types are stored in > > consecutive memory. I can then send that memory block across an > > interface and eliminate all the normal code associate with staging > > the values into a message record for sending and extracting the > > values from a received message record. > > Now that is quite nice and clever. > > -- > Jon Anthony > Synquiry Technologies, Ltd., Belmont, MA 02178, 617.484.3383 > "Nightmares - Ha! The way my life's been going lately, > Who'd notice?" -- Londo Mollari I'm glad you think so. Not being a expert at memory management techniques, this storage_pool is rather simple, does not allow deallocation, and simply allocates requested blocks in consequetive memory locations. Not very "full-featured" but for that simple job I described, it works nicely. I just can't use it for much anything else :) -- Samuel T. Harris, Senior Engineer Hughes Training, Inc. - Houston Operations 2224 Bay Area Blvd. Houston, TX 77058-2099 "If you can make it, We can fake it!" ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` Coding for Obscurity Alan E & Carmel J Brain 1997-11-20 0:00 ` Stephan Wilms @ 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Jos A. Horsmeier 1 sibling, 1 reply; 147+ messages in thread From: firewind @ 1997-11-20 0:00 UTC (permalink / raw) Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: > firewind wrote: > > I find myself using a construct like this a lot recently (snipped directly > > from code I'm working on right now): > > > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > > > For 'verbose' code this would be written: > > > > if(!to) { > > if(!to = malloc(sizeof *to)) { > > return(NULL); > > } > > } > > > > I find this unacceptable. The first form is understood well enough anyway > > The > > > > if(foo() || bar()) > > > > construct may seem obfuscated and weird to you, it is the way the logic of > > some people's minds work. > No further evidence, I rest my case. > Would anyone in comp.lang.c like to comment? From the new Subject: I assume you have drawn the conclusion that I code in the above manner (the first 'weird' if(), I don't use the second, but the point was that 'style imperialism' is stupid) to purposely obfuscate. Nothing can be further from the truth. Obfuscated code can be written in absolutely any language, by absolutely everyone. In a bad spot, a decidedly 'clean' coder can churn out a potful of spaghetti code. -- [- firewind -] [- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work) -] [- "You're just jealous because the voices talk to -me-." -] [- Have a good day, and enjoy your C. -] [- (on a crusade of grumpiness where grumpiness is due) -] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Coding for Obscurity 1997-11-20 0:00 ` firewind @ 1997-11-20 0:00 ` Jos A. Horsmeier 0 siblings, 0 replies; 147+ messages in thread From: Jos A. Horsmeier @ 1997-11-20 0:00 UTC (permalink / raw) firewind wrote: | Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: | > firewind wrote: | > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); | > > | > > For 'verbose' code this would be written: | > > | > > if(!to) { | > > if(!to = malloc(sizeof *to)) { | > > return(NULL); | > > } | > > } | > > | > > I find this unacceptable. The first form is understood well enough anyway | > > The if(foo() || bar()) construct may seem obfuscated and weird to you, it | > > is the way the logic of some people's minds work. | > No further evidence, I rest my case. | > Would anyone in comp.lang.c like to comment? | From the new Subject: I assume you have drawn the conclusion that I code in | the above manner (the first 'weird' if(), I don't use the second, but the | point was that 'style imperialism' is stupid) to purposely obfuscate. Nothing | can be further from the truth. Obfuscated code can be written in absolutely | any language, by absolutely everyone. In a bad spot, a decidedly 'clean' | coder can churn out a potful of spaghetti code. Absolutely true. I don't want to start a 'style war' but I do want to comment; I tend to accept any style of code that I can _pronounce_; for example, your first if statement above doesn't look weird or obfuscated to me at all; to me, it reads: if I don't have a 'to' and if I can't get a 'to' I'm out of here. As a matter of fact I use (the negation of) this construct regularly: if I have a 'to' or if I can get a 'to', do the job: if (to || (to= malloc(sizeof *to))) <do the job> else return NULL; it saves me a couple of 'not's and it shows a bit more positive attitude ;-) kind regards, Jos aka jos@and.nl ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` firewind ` (3 preceding siblings ...) 1997-11-20 0:00 ` Coding for Obscurity Alan E & Carmel J Brain @ 1997-11-20 0:00 ` Andy Knight 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Terry Richards 5 siblings, 1 reply; 147+ messages in thread From: Andy Knight @ 1997-11-20 0:00 UTC (permalink / raw) Your credibility is brought in to question when you present code that has been "snipped directly from code..." that can not possibly compile. Then you expand this codswallop into its supposed "verbose" form into something which is equally nonsensical. I'm off to adjust my filters. firewind wrote in message <64qsf0$ccc@dfw-ixnews11.ix.netcom.com>... >Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote: >> Peter Seebach wrote: >> > Can you honestly point to anyone claiming that "impenetrable" is a >> > sign of superiority out of the IOCCC? > >> There are plenty of people who use C since it is "cool", but just can't >> say what is so cool with it. It is cool because Mom can't understand it. >> No, they won't say that. > >So, you insult a great many professional C programmers, and hobbyists, et >cetra by comparing them to an adolescent who just follows the crowd? The >crowd is gaping at OOP at the moment. C is not OOP. > >> You can identify that kind of people by the >> lack of comments in the code. They *want* it that way - and they are >> many! > >I very seldom comment my code at the first writing. I prefer to just code >and get it done, then go back later and add comments, but -only- to >code which is not easily understood. > >> > Efficient is good. Tight can be good. Impenetrable is generally not >> > good. > >> When "efficient" and "tight" means as few keystrokes as possible, it >> isn't good. > >Why not? You are associating 'few keystrokes' with 'unintelligible' and >'brokenly using bad self-optimization techniques' which is not correct. > >> Efficient C code usually means that you take >> responsabilities >> that the optimizer should really do for you, and do that through >> questionable backdoors in the language. Case switches jumping into >> while loops is one example. > >'Questionable backdoors'? Some might disagree. BTW, last time I checked, >the C standard didn't garuntee there is an optimizer around to babysit you. > >> > I disagree with at least the implications of your conclusion. Writing, >> > on purpose, impenetrable, bad, inefficient, and ugly code is one of the >> > best ways to comprehend good code better. It's all well and good to say >> > "look, here's a good way to do this". It's just as good to say "and look, >> > here's a bad way". > >> > You can't understand fully what makes good code good without understanding >> > just as fully what makes bad code bad. > >> When you show the bad way to those kids, they think it is WAAAY cool! >> They will use any stinking obscure construction just because "it is >> valid C code". > >Again this insulting analogy. > >> Simple example from real life: > >> if (call_this() || call_that()); > >> Valid, yes. Better than > >> if (!call_this()) call_that(); > >> or more clear forms in other languages? >> Some people actually think so. > >I find myself using a construct like this a lot recently (snipped directly >from code I'm working on right now): > >if(!to && !(to = malloc(sizeof *to)))) return(NULL); > >For 'verbose' code this would be written: > >if(!to) { > if(!to = malloc(sizeof *to)) { > return(NULL); > } >} > >I find this unacceptable. The first form is understood well enough anyway: >If 'to' is not valid and an attempt to make 'to' valid fails, return an error. > >The > >if(foo() || bar()) > >construct may seem obfuscated and weird to you, it is the way the logic of >some people's minds work. To insult these people by comparing them to >fickle adolescents is simply out of line. > >-- >[- wind -] >[- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com work) -] >[- "You're just jealous because the voices talk -] >[- Have a good day, and enjoy your -] >[- (on a crusade of grumpiness where grumpiness is -] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-20 0:00 ` Programming language vote - results Andy Knight @ 1997-11-20 0:00 ` firewind 0 siblings, 0 replies; 147+ messages in thread From: firewind @ 1997-11-20 0:00 UTC (permalink / raw) Andy Knight <KnighA@tetraworld.com> wrote: > Your credibility is brought in to question when you present code that has > been "snipped directly from code..." that can not possibly compile. And I suppose you have never in your life made a typo? > Then you > expand this codswallop into its supposed "verbose" form into something which > is equally nonsensical. > I'm off to adjust my filters. I'm deeply hurt. -- [- firewind -] [- email: firewind@metroid.dyn.ml.org (home), firewind@aurdev.com (work) -] [- "You're just jealous because the voices talk to -me-." -] [- Have a good day, and enjoy your C. -] [- (on a crusade of grumpiness where grumpiness is due) -] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` firewind ` (4 preceding siblings ...) 1997-11-20 0:00 ` Programming language vote - results Andy Knight @ 1997-11-20 0:00 ` Terry Richards 1997-11-20 0:00 ` Andy Knight ` (2 more replies) 5 siblings, 3 replies; 147+ messages in thread From: Terry Richards @ 1997-11-20 0:00 UTC (permalink / raw) [big snip] > > Simple example from real life: > > > if (call_this() || call_that()); > > > Valid, yes. Better than > > > if (!call_this()) call_that(); > > > or more clear forms in other languages? > > Some people actually think so. > > I find myself using a construct like this a lot recently (snipped directly > from code I'm working on right now): > > if(!to && !(to = malloc(sizeof *to)))) return(NULL); > > For 'verbose' code this would be written: > > if(!to) { > if(!to = malloc(sizeof *to)) { > return(NULL); > } > } > > I find this unacceptable. The first form is understood well enough anyway: > If 'to' is not valid and an attempt to make 'to' valid fails, return an error. > > The > > if(foo() || bar()) > > construct may seem obfuscated and weird to you, it is the way the logic of > some people's minds work. [more snippage] Guys, I'm not sure who wrote what here so I've removed all the names. All of these constructs are flat out wrong. As far as I can remember, neither C or C++ guarantees that the clauses in a condition will be evaluated in the order you wrote them. IOW, if (call_this() || call_that()); could compile as if it where written: if (call_that() || call_this()); which could have different results. The malloc example *probably* has enough parentheses to force it to work in the right order but the fact is that the code is obscure at best and wrong at worst. It is also no more efficient when compiled than the equivalent construct: if (!call_this()) call_that(); Which, incidentally, is one *less* key stroke if you use a tab for the indent. Count 'em - I added four and deleted 5. I would not accept this code at a walkthrough. -- Terry Richards Terry Richards Software ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-20 0:00 ` Terry Richards @ 1997-11-20 0:00 ` Andy Knight 1997-11-23 0:00 ` Alex Krol 1997-11-25 0:00 ` William Tanksley 2 siblings, 0 replies; 147+ messages in thread From: Andy Knight @ 1997-11-20 0:00 UTC (permalink / raw) Terry Richards wrote in message <347440AD.35DF@idt.net>... [ snip ] >All of these constructs are flat out wrong. As far as I can remember, >neither C or C++ guarantees that the clauses in a condition will be >evaluated in the order you wrote them. IOW, > >if (call_this() || call_that()); > >could compile as if it where written: > >if (call_that() || call_this()); > >which could have different results. > No it won't. The left-to-right evaluation is well defined. [ snip ] ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-20 0:00 ` Terry Richards 1997-11-20 0:00 ` Andy Knight @ 1997-11-23 0:00 ` Alex Krol 1997-11-25 0:00 ` William Tanksley 2 siblings, 0 replies; 147+ messages in thread From: Alex Krol @ 1997-11-23 0:00 UTC (permalink / raw) Terry Richards wrote: > Guys, > As far as I can remember, > neither C or C++ guarantees that the clauses in a condition will be > evaluated in the order you wrote them. IOW, > > if (call_this() || call_that()); > > could compile as if it where written: > > if (call_that() || call_this()); > > which could have different results. No, you are wrong. The Standard guarantees that in (expr1 || expr2) expr2 would be evaluated if and only if expr1 is evaluated to 0; in (expr1 && expr2) expr2 would be evaluated if and onty if expr1 is evaluated to non-zero. To guarantee this, order of evaluation must be guaranteed also. This is true both for C and C++. Regards, Alex Krol ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-20 0:00 ` Terry Richards 1997-11-20 0:00 ` Andy Knight 1997-11-23 0:00 ` Alex Krol @ 1997-11-25 0:00 ` William Tanksley 1997-11-26 0:00 ` Ron Natalie 2 siblings, 1 reply; 147+ messages in thread From: William Tanksley @ 1997-11-25 0:00 UTC (permalink / raw) In article <347440AD.35DF@idt.net> trs@idt.net writes: >[big snip] >> > Simple example from real life: >> > if (call_this() || call_that()); >> I find myself using a construct like this a lot recently (snipped directly >> from code I'm working on right now): >> if(!to && !(to = malloc(sizeof *to)))) return(NULL); >All of these constructs are flat out wrong. As far as I can remember, >neither C or C++ guarantees that the clauses in a condition will be >evaluated in the order you wrote them. IOW, According to the ANSI standard and K&R, as well as universal prior practice, the boolean logical operators are short-circuiting. This means that they MUST exectute in order. In fact, this is required explicitly by ANSI and K&R. >The malloc example *probably* has enough parentheses to force it to work >in the right order but the fact is that the code is obscure at best and >wrong at worst. It is also no more efficient when compiled than the >equivalent construct: It'll work, so long as the library returns zeroes for nulls. I personally find it more readable than its stretched alternative, although for most other purposes I'd use the stretch. >if (!call_this()) > call_that(); >Which, incidentally, is one *less* key stroke if you use a tab for the >indent. Count 'em - I added four and deleted 5. But then, I use an editor which is made to cut down on such keystrokes. But who's counting. >I would not accept this code at a walkthrough. I'd have to see the surrounding design -- the malloc example looks dismaying, but there might be a reason which I can't imagine to not know and not care whether a pointer was initialized. The if( this() || that() ); example I would toss right out -- but then I've NEVER seen that written anywhere. this() || that(); works exactly as well, and doesn't tempt the code maintainer to assume that the semicolon was a typo. It's worth noting that using the short circuiting of 'or' is very common in many languages. Note some of the nicer aspects of Perl: "open file or die". Now THAT'S an idiom -- and me a good Python man :). >Terry Richards -Billy ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` William Tanksley @ 1997-11-26 0:00 ` Ron Natalie 1997-11-27 0:00 ` William Tanksley 0 siblings, 1 reply; 147+ messages in thread From: Ron Natalie @ 1997-11-26 0:00 UTC (permalink / raw) William Tanksley wrote: > > > According to the ANSI standard and K&R, as well as universal prior > practice, the boolean logical operators are short-circuiting. This > means that they MUST exectute in order. In fact, this is required > explicitly by ANSI and K&R. The spec calls these sequence points. Furthermore, && and || are required not to execute the right operand if the left side evaluates to false (in the case of and) or true (in the case of or). > The malloc example *probably* has enough parentheses to force it to > work in the right order but the fact is that the code is obscure at > best and wrong at worst. It is also no more efficient when compiled > than the equivalent construct: Assuming to is a pointer, there's nothing wrong with the statement as written by the original poster. PARENS do NOT AFFECT ORDERING in C/C++, they only affect the binding of the operations. > It'll work, so long as the library returns zeroes for nulls. It works no matter what. The constant zero is the null pointer constant. If malloc returns a null pointer regardless of it's machine representation, testing it for equality against an integer zero (or the boolean not) will work. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-26 0:00 ` Ron Natalie @ 1997-11-27 0:00 ` William Tanksley 1997-11-27 0:00 ` Lawrence Kirby 1997-11-28 0:00 ` Shmuel (Seymour J.) Metz 0 siblings, 2 replies; 147+ messages in thread From: William Tanksley @ 1997-11-27 0:00 UTC (permalink / raw) In article <347C420A.2B18@sensor.com> Ron Natalie <ron@sensor.com> writes: >William Tanksley wrote: >> The malloc example *probably* has enough parentheses to force it to >> work in the right order but the fact is that the code is obscure at >> best and wrong at worst. It is also no more efficient when compiled >> than the equivalent construct: I did NOT write this. I replied to this. I disagree utterly with it. >> It'll work, so long as the library returns zeroes for nulls. >It works no matter what. The constant zero is the null pointer >constant. If malloc returns a null pointer regardless of it's >machine representation, testing it for equality against an >integer zero (or the boolean not) will work. I did write this. NULL is defined as "(void*)0". I've never seen a compiler which failed to have (int)NULL be equal to 0 as well, but seeing one would not shock me -- according to K&R 2 (I don't have ANS C available right now) ANS doesn't explicitly require that. The worst part of that code, as far as I'm concerned, isn't the use of pointers as booleans; after all, I can't imagine why a vendor would EVER make non-zero NULL returns, especially since it would have to do a LOT of work to make them meet the other requirements. The bad part is that it assumes that a pointer in an unknown state will be either NULL or allocated. Ick. However, it could be that all the other code in the application is a model of clear and precise code, so those are obviously the only two possible states of the pointer at that point. If so, that's acceptable code. -Billy ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-27 0:00 ` William Tanksley @ 1997-11-27 0:00 ` Lawrence Kirby [not found] ` <65keij$mkd$1@nerd.apk.net> 1997-11-28 0:00 ` Shmuel (Seymour J.) Metz 1 sibling, 1 reply; 147+ messages in thread From: Lawrence Kirby @ 1997-11-27 0:00 UTC (permalink / raw) In article <65ih8m$pqt$1@news1.ucsd.edu> wtanksle@sdcc10.ucsd.edu "William Tanksley" writes: ... >NULL is defined as "(void*)0". It could also be written as #define NULL 0 in C, and it must be written like that in C++. > I've never seen a compiler which failed to >have (int)NULL be equal to 0 as well, but seeing one would not shock me -- >according to K&R 2 (I don't have ANS C available right now) ANS doesn't >explicitly require that. That is correct - converting a pointer to an integer has an implementation-defined result if it will fit in the integer, undefined if not. There are no special cases for conversion in that direction. >The worst part of that code, as far as I'm concerned, isn't the use of >pointers as booleans; after all, I can't imagine why a vendor would EVER >make non-zero NULL returns, especially since it would have to do a LOT of >work to make them meet the other requirements. Actually that's not true. All the implementor has to do is that ensure that whenever a null pointer constant is converted to a pointer type, the result has the correct representation for a null pointer of that type. For comparison against zero you can simply take the view that the zero is converted to the appropriate pointer type so the comparison simply works. > The bad part is that it >assumes that a pointer in an unknown state will be either NULL or >allocated. Ick. However, it could be that all the other code in the >application is a model of clear and precise code, so those are obviously >the only two possible states of the pointer at that point. If so, that's >acceptable code. A pointer value can be one of the following in C: 1. null 2. a pointer to a valid object (or function for a function pointer) 3. a pointer to one past the end of a valid object 4. Indeterminate. In the last case it is not valid to even look at the value in the code. Indeterminate pointers are, for example: 1. the values of uninitialised automatic variables 2. a pointer to an automatic variable which has since been destroyed because the function defining it returned or was longjmp'd out of 3. a pointer to dynamic memory that has been freed 4. a pointer to a FILE that has been closed. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <65keij$mkd$1@nerd.apk.net>]
* Re: Programming language vote - results [not found] ` <65keij$mkd$1@nerd.apk.net> @ 1997-11-27 0:00 ` Kaz Kylheku 0 siblings, 0 replies; 147+ messages in thread From: Kaz Kylheku @ 1997-11-27 0:00 UTC (permalink / raw) In article <65keij$mkd$1@nerd.apk.net>, Jim Showalter <ald103@aldhfn.org> wrote: >Lawrence Kirby (fred@genesis.demon.co.uk) wrote: >: In the last case it is not valid to even look at the value in the code. > ^^^^^^^^^^^^^^^^^^^^^^ > Excuse my ignorance, but I've noticed several references to the >above here lately and - although I don't think I lack imagination >- I must admit I haven't a clue as to what ill fortune may befall >a program that peeks at this ominous <indeterminate pointer value>. > >Really, I simply <must> know! :-) One day you may study computer architecture and find out that in some architectures, loading an invalid pointer into an address register will cause an exception. Incidentally, you need look no further than you 80x86 based PC to find such an architecture. In protected mode, if you load an illegal selector into a segment register, guess what happens. Any use of a pointer value may cause such an exception in the hardware. By imposing no requirements on what should happen, the standard makes it easier to implement C on such architectures. Essentially, it says ``Implementor, in the true spirit of C, you may simply translate the use of such an indeterminate value as usual and let all hell break loose''. :))) Of course, this sort of permissiveness means that the programmer has to know what he or she is doing, and must exercise care in order to create correct programs. Not having the patience or desire to learn the abstract language definition, most immature programmers opt out by relying instead their knowledge of how some particular hardware works---which is, after all, simpler and easier to understand than an abstract programming language description. Since their particular hardware does not trap on the use of illegal pointers, they wonder why the behavior is undefined when an indeterminate pointer value is used. Since their particular hardware allows any type to be aligned on any byte address, they wonder what alignment is and why they should every worry about it when casting pointers. Since on their particular hardware, pointers are all represented in the same way, they wonder why all the fuss about using (void **) as a generic pointer to pointer. Etc. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-27 0:00 ` William Tanksley 1997-11-27 0:00 ` Lawrence Kirby @ 1997-11-28 0:00 ` Shmuel (Seymour J.) Metz 1997-12-01 0:00 ` FRS DES 1 sibling, 1 reply; 147+ messages in thread From: Shmuel (Seymour J.) Metz @ 1997-11-28 0:00 UTC (permalink / raw) William Tanksley wrote: > NULL is defined as "(void*)0". I've never seen a compiler which failed to > have (int)NULL be equal to 0 as well, but seeing one would not shock me -- > according to K&R 2 (I don't have ANS C available right now) ANS doesn't > explicitly require that. > > The worst part of that code, as far as I'm concerned, isn't the use of > pointers as booleans; after all, I can't imagine why a vendor would EVER > make non-zero NULL returns, The obvious reason is to ensure that attempts to use a null pointer to access data will be trapped, instead of producing spurious output or storage overlays. Of course, if the low end of the address space is guarantied to be invalid, then the value 0 will accomplish that, but often 0 is a valid address. Shmuel (Seymour J.) Metz -- Shmuel (Seymour J.) Metz Senior Software SE The values in from and reply-to are for the benefit of spammers: reply to domain eds.com, user msustys1.smetz or to domain gsg.eds.com, user smetz. Do not reply to spamtrap@library.lspace.org ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-28 0:00 ` Shmuel (Seymour J.) Metz @ 1997-12-01 0:00 ` FRS DES 0 siblings, 0 replies; 147+ messages in thread From: FRS DES @ 1997-12-01 0:00 UTC (permalink / raw) In article <347F1CAC.6602@gsg.eds.com>, "Shmuel (Seymour J.) Metz" <nospam@gsg.eds.com> writes: >William Tanksley wrote: > NULL is defined as "(void*)0". I've never seen a >compiler which failed to > have (int)NULL be equal to 0 as well, but seeing >one would not shock me -- > according to K&R 2 (I don't have ANS C available >right now) ANS doesn't > explicitly require that. > > The worst part of that >code, as far as I'm concerned, isn't the use of > pointers as booleans; after >all, I can't imagine why a vendor would EVER > make non-zero NULL returns, > The obvious reason is to ensure that attempts to use a null pointer >to access data will be trapped, instead of producing spurious output >or storage overlays. Of course, if the low end of the address space >is guarantied to be invalid, then the value 0 will accomplish that, but often >0 is a valid address. Shmuel (Seymour J.) Metz -- >Shmuel (Seymour J.) Metz Senior Software SE This msg has nothing to do with APL. Please trim comp.lang.apl from replies to this msg, or start a new (non-crossposted) thread. -David E. Siegel Software Developer, LEX2000, Inc (Formerly Financial Reporting Software, or FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Ingemar Ragnemalm 1997-11-18 0:00 ` firewind @ 1997-11-18 0:00 ` Kevin Swan 1997-11-29 0:00 ` Ingemar Ragnemalm 1997-11-18 0:00 ` Lawrence Kirby ` (2 subsequent siblings) 4 siblings, 1 reply; 147+ messages in thread From: Kevin Swan @ 1997-11-18 0:00 UTC (permalink / raw) Ingemar Ragnemalm (ingemar@lysator.liu.se) wrote: : There are plenty of people who use C since it is "cool", but just can't : say what is so cool with it. It is cool because Mom can't understand it. : No, they won't say that. You can identify that kind of people by the : lack of comments in the code. They *want* it that way - and they are : many! Huh? What are you talking about? Do you *really* think that's it? I use C, and I don't mind telling you why. It has nothing to do with how easy or hard it is, it has to do with how fast it is. For small to medium sized programs, development time is fairly quick. In terms of execution speed, it simply doesn't get any faster than compiled C code. It puts you just above the assembly level, even permitting you to very easily work in assembly, if you want to optimize a tight little loop. I try extra hard to make my C code EASY to read. I comment generously. I find the syntax simple and intuitive, except when you get into pointers to pointers to pointers to .... and even then, its logical. Why would people *want* a language that was difficult to work in? That's called "assembly." If you think C is so difficult, why the they choose to model Java's syntax after C? After all, Java was intended to be one of the easiest possible languages to learn, with a very shallow learning curve, and has been quite successful at it. I can't even venture a guess at why you made the comments you did. It almost sounds like you're mad, or resentful at C programmers, but I can't imagine why. Perhaps you're jealous of something, or got a low mark in your C course, and are taking it out on the language. At any rate, I suggest you give it a second look. Its easy to learn, very fast, and an industry standard. Kev. C, Java, and Smalltalk programmer. -- Kevin Swan BCSH My university broke my email. If you want to email me, please send it to 013639s@dragon.acadiau.ca Acadia University How's my posting? Call 1-800-DEV-NULL ** Fatal Error [1]: 'Win95' virus detected on /dev/hda1; Formatting ... ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Kevin Swan @ 1997-11-29 0:00 ` Ingemar Ragnemalm 1998-09-10 0:00 ` Steven Katz 0 siblings, 1 reply; 147+ messages in thread From: Ingemar Ragnemalm @ 1997-11-29 0:00 UTC (permalink / raw) Kevin Swan wrote: > > Ingemar Ragnemalm (ingemar@lysator.liu.se) wrote: > > : There are plenty of people who use C since it is "cool", but just can't > : say what is so cool with it. It is cool because Mom can't understand it. > : No, they won't say that. You can identify that kind of people by the > : lack of comments in the code. They *want* it that way - and they are > : many! > > Huh? What are you talking about? Do you *really* think that's it? I am talking about people I have met, and don't want to work with. I wasn't talking about everybody. Re-read. > I use > C, and I don't mind telling you why. It has nothing to do with how easy or > hard it is, it has to do with how fast it is. For small to medium sized > programs, development time is fairly quick. In terms of execution speed, > it simply doesn't get any faster than compiled C code. It puts you just > above the assembly level, even permitting you to very easily work in > assembly, if you want to optimize a tight little loop. Execution speed is no better or worse than any other high-level language (although it is queastionable if C is high-level), unless the code generator and optimizer are poor. I've made comparisons. Have you? I find C fairly comfortable for small hacks, like UNIX text filters. Entire applications in C require you to enforce lots of rules that the language doesn't have, or you get a mess. > I try extra hard to make my C code EASY to read. I comment generously. If you comment generously, there's no reason to take offense when I complain about people who don't. I work with people who make clean, straight, readable C-code and comment it well. I have no problems with them. We regularily interface Pascal code and C code with great results. > I find the syntax simple and intuitive, except when you get into pointers > to pointers to pointers to .... and even then, its logical. I don't. I find it clumsy, unnecessarily far from english, and many constructs are little more than primitive macros. When reading other people's code, I find Pascal-like languages comfortable since they translate straight to english. With C-style languages, I have to do one more step. It isn't *hard*, but it is harder than the straight- forward english-like syntax. If you think in C, OK, then I guess it is for you. > Why would people *want* a language that was difficult to work in? That's > called "assembly." If you think C is so difficult, why the they choose to > model Java's syntax after C? After all, Java was intended to be one of the > easiest possible languages to learn, with a very shallow learning curve, > and has been quite successful at it. Not because it was *good* but because it was *popular*. And Java is definitely not the easiest to learn. It is just hyped to the level where everybody feels they *must* learn it. Do you find AWT easy to work with? > I can't even venture a guess at why you made the comments you did. It > almost sounds like you're mad, or resentful at C programmers, but I can't > imagine why. I am a bit irritated at C users who refuse to make their code readable, by using the least readable constructs and refusing to comment the code. They do exist, and they are many, especially at universities. Mad, well, perhaps at one thing: how C programmers tend to flame other high-level languages without knowing what they are talking about. You know, like "my dad is stronger than your dad". > Perhaps you're jealous of something, or got a low mark in > your C course, and are taking it out on the language. Keep the personal flames out of this. If you need to know, I know C well, have written much C code, including fairly large applications. I used Pascal rather little at the university, since all the courses only used vanilla Pascal. I remember Simula was fascinating for its OO features (before C++ even existed). I mostly used assembly at home. I started application programming in C, since that's what people said was what I "should" use. When I switched to Pascal, total development time was cut in half. Yes, it takes a little more time to write the initial code, but it takes *much* less time to get the bugs out. My conclusion is that Algol-style syntax suits my programming style well. > At any rate, I > suggest you give it a second look. Its easy to learn, very fast, and an > industry standard. I look at it every day, thank you very much. I just wish I could do that a bit less, with more time in Pascal, Ada, Simula etc. /Ingemar ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-29 0:00 ` Ingemar Ragnemalm @ 1998-09-10 0:00 ` Steven Katz 0 siblings, 0 replies; 147+ messages in thread From: Steven Katz @ 1998-09-10 0:00 UTC (permalink / raw) On Sat, 29 Nov 1997 00:53:42 +0000, Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote: There's a great programming language reference series published by Macmillan. See http://www.mcp.com/offers/prog_promo/index.html ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Ingemar Ragnemalm 1997-11-18 0:00 ` firewind 1997-11-18 0:00 ` Kevin Swan @ 1997-11-18 0:00 ` Lawrence Kirby 1997-11-24 0:00 ` Martin M Dowie 1997-11-19 0:00 ` Peter Seebach 1997-11-19 0:00 ` Alan E & Carmel J Brain 4 siblings, 1 reply; 147+ messages in thread From: Lawrence Kirby @ 1997-11-18 0:00 UTC (permalink / raw) In article <3470EF6E.F74@lysator.liu.se> ingemar@lysator.liu.se "Ingemar Ragnemalm" writes: ... >> Efficient is good. Tight can be good. Impenetrable is generally not >> good. > >When "efficient" and "tight" means as few keystrokes as possible, it >isn't good. Agreed but that don't mean that in C any more than the do in any other language. >Efficient C code usually means that you take >responsabilities >that the optimizer should really do for you, and do that through No, it means you work in partnership with the optimiser. You deal with the higher level issues such as algorithms and general approach and the optimiser deals with the lower level details. >questionable backdoors in the language. Case switches jumping into >while loops is one example. Perhaps you could give an example of something that is used more than once in a blue moon? C supports goto. It is rarely used in practice but there are some situations where it is simply the best approach. The vast majority of cases of coding efficnently in C don't depend on these sort of tricks but they are there when you need them and occasionally you do. >> I disagree with at least the implications of your conclusion. Writing, >> on purpose, impenetrable, bad, inefficient, and ugly code is one of the >> best ways to comprehend good code better. It's all well and good to say >> "look, here's a good way to do this". It's just as good to say "and look, >> here's a bad way". > >> You can't understand fully what makes good code good without understanding >> just as fully what makes bad code bad. > >When you show the bad way to those kids, they think it is WAAAY cool! >They will use any stinking obscure construction just because "it is >valid C code". Are you talking about people who are going to develop serious code or not? >Simple example from real life: > >if (call_this() || call_that()); > >Valid, yes. Better than > >if (!call_this()) call_that(); The latter is certainly better C style and isn't going to be less efficient than the former. >or more clear forms in other languages? That is a matter of opinion. I doubt whether you will find a demonstrably clearer form in another language. >Some people actually think so. I'm sure some do. It is possible to program using a bad style in any language. You're arguing more about the culture that has grown up around C than about the language itself. For better or for worse C became the mass-market language of the 80's and the result of that is a lot of people out there using it who have never really learnt the principles of good programming. This isn't helped by the plethora of awful books that have been published purporting to teach C. This is why the emphasis in comp.lang.c is on programming in standard C in an efficient but more importantly clear way. Desire to write "cool" code is an insignificant problem compared with simple lack of knowledge and misinformation. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Lawrence Kirby @ 1997-11-24 0:00 ` Martin M Dowie 1997-11-25 0:00 ` Mark Wilden 1997-11-25 0:00 ` Kaz Kylheku 0 siblings, 2 replies; 147+ messages in thread From: Martin M Dowie @ 1997-11-24 0:00 UTC (permalink / raw) In article <879863453snz@genesis.demon.co.uk>, Lawrence Kirby <fred@genesis.demon.co.uk> writes >In article <3470EF6E.F74@lysator.liu.se> > ingemar@lysator.liu.se "Ingemar Ragnemalm" writes: > >... >Perhaps you could give an example of something that is used more than once >in a blue moon? C supports goto. It is rarely used in practice but there >are some situations where it is simply the best approach. i've heard many people use this "where it is simply the best approach" 'reason' - care to given an example? and please don't say to stop doing one thing quickly in order to do another - that is simply indicative of a poorly analysed and designed system. Ada also supports a 'goto' statement (though with much tighter controls) but the only valid reason i've ever come across for using it is for automated code generators. -- Martin M Dowie ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-24 0:00 ` Martin M Dowie @ 1997-11-25 0:00 ` Mark Wilden 1997-11-25 0:00 ` Martin M Dowie 1997-11-26 0:00 ` FRS DES 1997-11-25 0:00 ` Kaz Kylheku 1 sibling, 2 replies; 147+ messages in thread From: Mark Wilden @ 1997-11-25 0:00 UTC (permalink / raw) Martin M Dowie wrote: > > i've heard many people use this "where it is simply the best approach" > 'reason' - care to given an example? [of goto] I've found goto the best way to branch in a simple state machine. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` Mark Wilden @ 1997-11-25 0:00 ` Martin M Dowie 1997-11-26 0:00 ` Lawrence Kirby 1997-11-26 0:00 ` FRS DES 1 sibling, 1 reply; 147+ messages in thread From: Martin M Dowie @ 1997-11-25 0:00 UTC (permalink / raw) In article <347B17AC.5A53@mWilden.com>, Mark Wilden <Mark@mWilden.com> writes >Martin M Dowie wrote: >> >> i've heard many people use this "where it is simply the best approach" >> 'reason' - care to given an example? [of goto] > >I've found goto the best way to branch in a simple state machine. in what why is this 'the best'? surely an enumeration type containing each possible state together with a local static variable used in an infinite loop would produce more readable safer and _provable_ code? or is that loop up to the top of a case/guarded select statement too much?.. -- Martin M Dowie ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` Martin M Dowie @ 1997-11-26 0:00 ` Lawrence Kirby 0 siblings, 0 replies; 147+ messages in thread From: Lawrence Kirby @ 1997-11-26 0:00 UTC (permalink / raw) In article <$2oaKBAp0xe0EwNL@dowie-cs.demon.co.uk> martin@dowie-cs.demon.co.uk "Martin M Dowie" writes: >In article <347B17AC.5A53@mWilden.com>, Mark Wilden <Mark@mWilden.com> >writes >>Martin M Dowie wrote: >>> >>> i've heard many people use this "where it is simply the best approach" >>> 'reason' - care to given an example? [of goto] A good example is breaking out of nested loops, say for code that is searching for a value in a 2 dimensional array datastructure. Possibly a more flexible form of the break statement would have been the answer here but since we don't have that goto is the best solution. The Pascal solution would probably be to create some sort of flag variable but that just obscures the algorithm which is not a good idea if it can be avoided. >>I've found goto the best way to branch in a simple state machine. > >in what why is this 'the best'? surely an enumeration type containing >each possible state together with a local static variable used in an >infinite loop would produce more readable safer and _provable_ code? You would need to demonstrate that it is any of these things. Most of the state machines I've written have taken the form you suggest but that is for a specific reason that I've tended to want to preserve the state between calls to the function containing the FSM, therefore the state needs to be held in a variable. Where that isn't the case a goto based implementation is quite natural. A FSM has structure but it is not of the same form as that supported by structured languages. So trying to implement it using structured language concepts isn't an automatic win. In fact by doing so you're adding an extra layer of complexity. >or >is that loop up to the top of a case/guarded select statement too >much?.. We're comparing two approaches, not asking in an absolute sense whether one approach is acceptable or not. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` Mark Wilden 1997-11-25 0:00 ` Martin M Dowie @ 1997-11-26 0:00 ` FRS DES 1 sibling, 0 replies; 147+ messages in thread From: FRS DES @ 1997-11-26 0:00 UTC (permalink / raw) << >Perhaps you could give an example of something that is used more than once >in a blue moon? C supports goto. It is rarely used in practice but there >are some situations where it is simply the best approach. >i've heard many people use this "where it is simply the best approach" >'reason' - care to given an example? and please don't say to stop doing >one thing quickly in order to do another - that is simply indicative of >a poorly analysed and designed system. > >Ada also supports a 'goto' statement (though with much tighter controls) >but the only valid reason i've ever come across for using it is for >automated code generators. This thread seems to have lost all connection to APL -- please delete comp.lang.apl for the newsgroup line or start a new thread. -David E. Siegel Software Developer, LEX2000, Inc (Formerly Financial Reporting Software, or FRS) FRSdes@AOL.COM ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-24 0:00 ` Martin M Dowie 1997-11-25 0:00 ` Mark Wilden @ 1997-11-25 0:00 ` Kaz Kylheku 1997-11-26 0:00 ` Peter Seebach 1997-12-02 0:00 ` ANDREAS LEITNER 1 sibling, 2 replies; 147+ messages in thread From: Kaz Kylheku @ 1997-11-25 0:00 UTC (permalink / raw) In article <t6Le5BAnmde0EwO$@dowie-cs.demon.co.uk>, Martin M Dowie <martin@dowie-cs.demon.co.uk> wrote: >In article <879863453snz@genesis.demon.co.uk>, Lawrence Kirby ><fred@genesis.demon.co.uk> writes >>In article <3470EF6E.F74@lysator.liu.se> >> ingemar@lysator.liu.se "Ingemar Ragnemalm" writes: >> >>... >>Perhaps you could give an example of something that is used more than once >>in a blue moon? C supports goto. It is rarely used in practice but there >>are some situations where it is simply the best approach. > >i've heard many people use this "where it is simply the best approach" >'reason' - care to given an example? and please don't say to stop doing >one thing quickly in order to do another - that is simply indicative of >a poorly analysed and designed system. The ``to goto or not goto'' debate has been settled decades ago. Both sides were wrong. :) Whether or not it is appropriate to use a goto depends on the programming language---namely, what control structures the language supports. If the language only supports GOTO-like structures, then your choice is made for you. In other cases it's not that clear. Suppose that you want to break out of some deeply nested block statement. If your language supports a ``break N'' statement, to break out of N nesting levels, or a ``break <name>'' where <name> is the name of the enclosing block from which you want to jump out, then you will use the break. If you don't have it, you either use a simple goto, or an extra variable plus a number of tests at each level. It must be remembered that goto is the most general and powerful control mechanism and is an important ``escape hatch''. Today, goto no longer calls for fear and disdain, because it isn't the monster that it was thought to be in the 60's. How recently have you come across a program that was rotten due to the abuse of goto? Is this really a valid concern? >Ada also supports a 'goto' statement (though with much tighter controls) >but the only valid reason i've ever come across for using it is for >automated code generators. That's an important application, given that some CASE tools generate code. In some cases, you could probably trust a goto-ridden automatically generated code more readily than hand-written structured code. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` Kaz Kylheku @ 1997-11-26 0:00 ` Peter Seebach 1997-12-02 0:00 ` ANDREAS LEITNER 1 sibling, 0 replies; 147+ messages in thread From: Peter Seebach @ 1997-11-26 0:00 UTC (permalink / raw) In article <65gaoj$f8u$1@helios.crest.nt.com>, Kaz Kylheku <kaz@helios.crest.nt.com> wrote: >How recently have you come across a program that was rotten due to the abuse of >goto? Is this really a valid concern? A friend of mine has been working with code like that. The author spent a week or two insisting that my friend's code was at fault for not opening files correctly. Files with names like "c:\temp\foo.tmp" no less. So, yes, there still is shoddy spaghetti code out there. -s -- seebs@plethora.net -- I am not speaking for my employer. Copyright '97 All rights reserved. This was not sent by my cat. C and Unix wizard - send mail for help, or send money for a consultation. Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam! Plethora . Net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-25 0:00 ` Kaz Kylheku 1997-11-26 0:00 ` Peter Seebach @ 1997-12-02 0:00 ` ANDREAS LEITNER 1997-12-02 0:00 ` Lawrence Kirby ` (2 more replies) 1 sibling, 3 replies; 147+ messages in thread From: ANDREAS LEITNER @ 1997-12-02 0:00 UTC (permalink / raw) Names are snipped (dont know who wrote what, sorry) : Whether or not it is appropriate to use a goto depends on the programming : language---namely, what control structures the language supports. : If the language only supports GOTO-like structures, then your choice is : made for you. In other cases it's not that clear. Suppose that you want : to break out of some deeply nested block statement. If your language : supports a ``break N'' statement, to break out of N nesting levels, : or a ``break <name>'' where <name> is the name of the enclosing block : from which you want to jump out, then you will use the break. If you : don't have it, you either use a simple goto, or an extra variable plus a : number : of tests at each level. Well, in my opinion the need to use a goto is in most (if not all) cases a sign that the design or the language lacks. (if (!design lacks) language lacks; :) I think goto debate is not recent anymore is because the majority of people have accepted the fact that goto provide unreadable code. Once we got a "coder" that produced lots of gotos, he was fired not onyl because of gotos but also because of the fact that a different programmer was able to rewrite a function without using one goto and also reducing the size of the function from 60 to 15 lines (as I remember correctly) I think this is the main reason why the goto-argument is not held anymore (or is it help by now?) : How recently have you come across a program that was rotten due to the : abuse of : goto? Is this really a valid concern? Yes, I've debugged a program that rebuild took over 30 minutes. Here to use the trail and error aproach to get an idea of the code costs too much time and money. (And is anoing) -- ANDREAS LEITNER alias nozone@sbox.tu-graz.ac.at ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-12-02 0:00 ` ANDREAS LEITNER @ 1997-12-02 0:00 ` Lawrence Kirby 1997-12-03 0:00 ` Billy Chambless 1997-12-02 0:00 ` Robert Dewar 1997-12-05 0:00 ` John Sullivan 2 siblings, 1 reply; 147+ messages in thread From: Lawrence Kirby @ 1997-12-02 0:00 UTC (permalink / raw) In article <6616ej$llt@fstgal00.tu-graz.ac.at> nozone@sbox.tu-graz.ac.at "ANDREAS LEITNER" writes: >Names are snipped (dont know who wrote what, sorry) > >: Whether or not it is appropriate to use a goto depends on the programming >: language---namely, what control structures the language supports. >: If the language only supports GOTO-like structures, then your choice is >: made for you. In other cases it's not that clear. Suppose that you want >: to break out of some deeply nested block statement. If your language >: supports a ``break N'' statement, to break out of N nesting levels, >: or a ``break <name>'' where <name> is the name of the enclosing block >: from which you want to jump out, then you will use the break. If you >: don't have it, you either use a simple goto, or an extra variable plus a >: number >: of tests at each level. > >Well, in my opinion the need to use a goto is in most (if not all) cases a >sign that the design or the language lacks. (if (!design lacks) language >lacks; :) It depends on how often that need arises. If (pulling vague numbers out of the air) a goto is appropriate every 10000 lines of code then the language can't seriously be considered deficient. Trying to eliminate the remaining gotos with manguage extensions would be over-engineering the language and counter-productive. >I think goto debate is not recent anymore is because the majority of people >have accepted the fact that goto provide unreadable code. It isn't a large debate any more because the issues involved are now pretty much understood. goto still has its place but it needs to be used carefully. The situations where it is apporpriate still exist when using a good structured language but are rare. >Once we got a >"coder" that produced lots of gotos, he was fired not onyl because of gotos >but also because of the fact that a different programmer was able to rewrite >a function without using one goto and also reducing the size of the function >from 60 to 15 lines (as I remember correctly) In that case the goto's were just a symptom, the programmer simply didn't know how to program well. He/she would most likely have managed to write bad and inefficient code in a language that doesn't support goto. >I think this is the main reason why the goto-argument is not held anymore >(or is it help by now?) I think many people avoid goto entirely now simply because of peer pressure. To actually type the word in their code would bring them out in a cold sweat! :-) This isn't a response based on reason however. Even in languages that don't support structured constructs to nay great extent (so you can't seriously avoid using goto) you can still write in a structured way. It just takes discipline and a degree of knowledge of how to go about it. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-12-02 0:00 ` Lawrence Kirby @ 1997-12-03 0:00 ` Billy Chambless 1997-12-03 0:00 ` Robert Dewar 0 siblings, 1 reply; 147+ messages in thread From: Billy Chambless @ 1997-12-03 0:00 UTC (permalink / raw) In article <881106132snz@genesis.demon.co.uk>, fred@genesis.demon.co.uk (Lawrence Kirby) writes: |> In article <6616ej$llt@fstgal00.tu-graz.ac.at> |> nozone@sbox.tu-graz.ac.at "ANDREAS LEITNER" writes: |> >Once we got a |> >"coder" that produced lots of gotos, he was fired not onyl because of gotos |> >but also because of the fact that a different programmer was able to rewrite |> >a function without using one goto and also reducing the size of the function |> >from 60 to 15 lines (as I remember correctly) |> In that case the goto's were just a symptom, the programmer simply didn't |> know how to program well. He/she would most likely have managed to write |> bad and inefficient code in a language that doesn't support goto. Indeed. While goto is, in K&R's words, "infinitely abusable", many other common programming language features are infinitely abusable. The programmer mentioned sounds incompetent; if you take goto's away from an incompetent programmer, they'll just find some other feature (pointers, for instance) to abuse. ;) GOTO is infinitely abusable, but so is the C-style switch statement, operator overloading, polymorphism, etc. |> I think many people avoid goto entirely now simply because of peer pressure. |> To actually type the word in their code would bring them out in a cold |> sweat! :-) This isn't a response based on reason however. Yup. CS grads especially, have had a religious prohibition of GOTO beat into their head. |> Even in languages that don't support structured constructs to nay great |> extent (so you can't seriously avoid using goto) you can still write in |> a structured way. It just takes discipline and a degree of knowledge of how |> to go about it. Exactly. One can write structured FORTRAN or BASIC with a little effort... or, for that matter, spaghetti Ada or C++. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-12-03 0:00 ` Billy Chambless @ 1997-12-03 0:00 ` Robert Dewar 0 siblings, 0 replies; 147+ messages in thread From: Robert Dewar @ 1997-12-03 0:00 UTC (permalink / raw) <<Yup. CS grads especially, have had a religious prohibition of GOTO beat into their head. >> That's an over-generalization, certainly it is something that I avoid. The trouble is of course that most university CS professors know zilch about programming, and manage to pass on their lack of knowledge very effectively to their students. Please note I said "most", not all. I know of several exceptions, in fact the Ada community tends to have quite a few university folks around who *do* know how to program (this of course is not a coincidence, those who know zilch about programming are much less likely to understand the advantages of Ada :-) ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-12-02 0:00 ` ANDREAS LEITNER 1997-12-02 0:00 ` Lawrence Kirby @ 1997-12-02 0:00 ` Robert Dewar 1997-12-05 0:00 ` John Sullivan 2 siblings, 0 replies; 147+ messages in thread From: Robert Dewar @ 1997-12-02 0:00 UTC (permalink / raw) <<Well, in my opinion the need to use a goto is in most (if not all) cases a sign that the design or the language lacks. (if (!design lacks) language lacks; :) I think goto debate is not recent anymore is because the majority of people have accepted the fact that goto provide unreadable code. Once we got a "coder" that produced lots of gotos, he was fired not onyl because of gotos but also because of the fact that a different programmer was able to rewrite a function without using one goto and also reducing the size of the function from 60 to 15 lines (as I remember correctly) I think this is the main reason why the goto-argument is not held anymore (or is it help by now?) >> I certainly don't want a rerun of the goto debate, but you should know that the above absolutely stated opinion is rejected by many people. It is certainly not the case that all gotos produce unreadable code. Good programmers often use a goto to improve the readability of the code (indeed that is the only reason for using gotos). A common exception for many people is that finite state machines are sometimes more easily represented with code using gotos. If this thread starts again, one hopes it does not, nothing new will be said, but you will see that the bottom line is that *some* people agree that gotos are evil and should never be used, but many people (including for example Wirth and Knuth) don't have this allergic reaction to gotos, and find useful uses for them. Note that the fact that the design of Ada 83 contains the goto, and that noone suggested putting the goto into annex J in Ada 95, should indicate that the sentiment that gotos are *sometimes* useful is widespread. Yes, of course we all know that an excessive use of gotos is a bad thing. So is an excessive amount of almost anything, e.g. salt, but that does not mean you should ban salt! ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-12-02 0:00 ` ANDREAS LEITNER 1997-12-02 0:00 ` Lawrence Kirby 1997-12-02 0:00 ` Robert Dewar @ 1997-12-05 0:00 ` John Sullivan 2 siblings, 0 replies; 147+ messages in thread From: John Sullivan @ 1997-12-05 0:00 UTC (permalink / raw) In article <6616ej$llt@fstgal00.tu-graz.ac.at>, ANDREAS LEITNER <nozone@sbox.tu-graz.ac.at> writes [snip] >Well, in my opinion the need to use a goto is in most (if not all) cases a >sign that the design or the language lacks. (if (!design lacks) language >lacks; :) >I think goto debate is not recent anymore is because the majority of people >have accepted the fact that goto provide unreadable code. Once we got a >"coder" that produced lots of gotos, he was fired not onyl because of gotos >but also because of the fact that a different programmer was able to rewrite >a function without using one goto and also reducing the size of the function >from 60 to 15 lines (as I remember correctly) Amazing how people's attitudes change over the years, isn't it? From the May/June'94 IEEE Institute, an article about John Backus receiving the Draper Prize for having developed Fortran: "Another of Fortran's breakthroughs was the GOTO statement, which was a uniquely simple and understandable means of structuring and modularizing programs." (Thanks to Seth Breidbart for finding this quote) John Sullivan ------------- remove the dots from the first three (Welsh) words for my real address ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Ingemar Ragnemalm ` (2 preceding siblings ...) 1997-11-18 0:00 ` Lawrence Kirby @ 1997-11-19 0:00 ` Peter Seebach 1997-11-19 0:00 ` Alan E & Carmel J Brain 4 siblings, 0 replies; 147+ messages in thread From: Peter Seebach @ 1997-11-19 0:00 UTC (permalink / raw) In article <3470EF6E.F74@lysator.liu.se>, Ingemar Ragnemalm <ingemar@lysator.liu.se> wrote: >Simple example from real life: >if (call_this() || call_that()); UGH! >Valid, yes. Better than >if (!call_this()) call_that(); >or more clear forms in other languages? >Some people actually think so. I have a hard time believing that. I will argue that call_this() || call_that(); is clear to sh and perl programmers. The redundant if() is just plain stupid, though - happily granted. Perhaps it devolved from an original doing something like if (call_this() || call_that()) do_something(); in which case, it would (arguably) make sense, and be perfectly idiomatic, just as it's idiomatic, though not the most simple, to say If you're going to the store, or you have a free moment, could you get me some orange juice? (Of course, in this case, if you stop wanting orange juice, you remove the entire statement.) Simplicity is not always the best mechanism for clarity. Anyone who thinks otherwise is entitled to try to read children's books for comprehension - it's very tiring, and in the end, *hard*, to read a lot of little tiny sentences. -s -- seebs@plethora.net -- I am not speaking for my employer. Copyright '97 All rights reserved. This was not sent by my cat. C and Unix wizard - send mail for help, or send money for a consultation. Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam! Plethora . Net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-11-18 0:00 ` Ingemar Ragnemalm ` (3 preceding siblings ...) 1997-11-19 0:00 ` Peter Seebach @ 1997-11-19 0:00 ` Alan E & Carmel J Brain 4 siblings, 0 replies; 147+ messages in thread From: Alan E & Carmel J Brain @ 1997-11-19 0:00 UTC (permalink / raw) Ingemar Ragnemalm wrote: > There are plenty of people who use C since it is "cool", but just can't > say what is so cool with it. It is cool because Mom can't understand it. > No, they won't say that. You can identify that kind of people by the > lack of comments in the code. They *want* it that way - and they are > many! > When you show the bad way to those kids, they think it is WAAAY cool! > They will use any stinking obscure construction just because "it is > valid C code". > > Simple example from real life: > > if (call_this() || call_that()); > > Valid, yes. Better than > > if (!call_this()) call_that(); > > or more clear forms in other languages? > Some people actually think so. Here's a post from some time ago. I've had numerous requests from people to circulate it around their offices. But no rebuttals.... > C is better than Ada because.... > > The first real-world C program I did was in 1980. Since 1983 I've been trying to > convince C hackers about the benefits of Ada. Those that actually were forced to do > some real project in Ada were quickly converted. But mainly, no-one tried. > > Trying to tell people about the benefits often leads to complete stonewalling. There > has to be a logical reason for this - few programmers have low IQs. > > I've finally become convinced that C really IS better than Ada, for the following > reasons: > > > FOR THE PROGRAMMER > > ..Hacking away in C is fun, you can add trapdoors and trojan horses real easy > > ..You can write neat stuff like the following code fragments: > > #define BITCOUNT(x) (((BX_(x)+(BX_(x)>>4)) & 0x0F0F0F0F) % 255) > #define BX_(x) ((x) - (((x)>>1)&0x77777777) \ > - (((x)>>2)&0x33333333) \ > - (((x)>>3)&0x11111111) > p = BX_(n); > > n = ((n>>1) & 0x55555555) | ((n<<1) & 0xaaaaaaaa); > n = ((n>>2) & 0x33333333) | ((n<<2) & 0xcccccccc); > n = ((n>>4) & 0x0f0f0f0f) | ((n<<4) & 0xf0f0f0f0); > n = ((n>>8) & 0x00ff00ff) | ((n<<8) & 0xff00ff00); > n = ((n>>16) & 0x0000ffff) | ((n<<16) & 0xffff0000); > > which is difficult to understand, and makes you look really, really clever, > even though it does something utterly trivial ( p is the number of bits in n, > and n ends up with its bit order reversed ) > > ..You'll always have a secure job, trying to make sense of other people's code > after they've left > > ..You'll always have a secure job, as with well-written, terse, tight and > efficient C YOU are the ONLY one who can easily understand your own code! > > ..You'll always have a secure job, as large C programs always have lots of bugs, > and require oodles of maintenance > > ..Compiling is really easy - even when the stuff you're compiling is utter > garbage, the compiler won't tell on you > > ..You can ignore most of your coding errors until quite late in the day - with > any luck, until you've left the project > > > FOR THE SUPPLIER > > ..You can always find C hackers, and they're dirt cheap > > ..With C, you get the initial build done quick, cheap and dirty, and make a > fortune over the next 10 years putting in new bugs while removing old ones. > > > FOR THE CUSTOMER > > ..Because programmers and suppliers tell you so. > > > > Ada is worse than C because > > ..Only Anal-retentive weenies who mumble about Quality and Professionalism > would get any fun out of Ada > > ..You'd get into the habit of writing stuff like > > with MACHINE_SPECIFIC; > > procedure COUNT_BITS_AND_REVERSE > ( THE_WORD : in out MACHINE_SPECIFIC.WORD_TYPE, > THE_COUNT : out MACHINE_SPECIFIC.BIT_COUNT_TYPE > ) is > > declare > > package BIT_OPS renames MACHINE_SPECIFIC.BIT_OPERATIONS; > > begin > > THE_COUNT := BIT_OPS.BIT_COUNT_OF(THE_WORD); > BIT_OPS.REVERSE_BIT_ORDER_OF(THE_WORD); > > exception > > when others => raise CODE_CORRUPTED_OR_HARDWARE_ERROR; > > end COUNT_BITS_AND_REVERSE; > > which any fool can easily understand, even though it does trap some of > the errors caused by the over-running array bounds in the C you've had > to PRAGMA INTERFACE to, soft errors, and hardware glitches. > Not only that, it works on 16, 32, 64, 48 etc bit machines as well. so > can't get lots of bucks writing different versions. > And then the compiler barfs, and tells you what you've done wrong! > > ..You spend a long time looking for a job, as your code on the last project > worked so well that the project completed on time, and you were no longer > needed. > > ..You spend a long time looking for a job, as the maintenance effort needed > consisted of 2 part-timers rather than the whole development team > > ..You spend a long time looking for a job, as no-one uses Ada > > ..Getting a Clean Compile of anything non-trivial is quite difficult. > > ..Your Ego takes a hammering by the compiler constantly showing you where > you made mistakes. And if not the compiler, the Linker! > > > FOR A SUPPLIER > > ..Ada programmers are rare and expensive. You can't hire cheap graduate coolies. > > ..It costs more initially to make a system, and it takes longer. Much worse, > there's almost no maintenance, so your only revenue is from the initial sale. > > > FOR A CUSTOMER > > ..Because the programmers and suppliers tell you so. > > > That's the bottom line, people. The only people who benefit from Ada are the > customers and users. The user riding on a 777 generally doesn't know that any > programming was involved, and the customers rely on advice from their suppliers. > > Until we understand that, all arguments regarding the qualities of Ada are > irrelevant. -- aebrain@dynamite.com.au <> <> How doth the little Crocodile | Alan & Carmel Brain| xxxxx Improve his shining tail? | Canberra Australia | xxxxxHxHxxxxxx _MMMMMMMMM_MMMMMMMMM abrain@cs.adfa.oz.au o OO*O^^^^O*OO o oo oo oo oo By pulling MAERKLIN Wagons, in 1/220 Scale ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` D'Arcy J.M. Cain ` (2 preceding siblings ...) 1997-10-16 0:00 ` Alan E & Carmel J Brain @ 1997-10-16 0:00 ` Randy MacDonald [not found] ` <01bcdad2$fa9fdf60$25a43a91@basil.omroep.nl> 4 siblings, 0 replies; 147+ messages in thread From: Randy MacDonald @ 1997-10-16 0:00 UTC (permalink / raw) In article <3444BFC6.794BDF32@druid.net>, "D'Arcy J.M. Cain" <darcy@druid.net> wrote: >Alan E & Carmel J Brain wrote: >> Every time someone says how terse and powerful C is, I think of APL. > >My favourite quote about APL - "I refuse to use any computer language >in which the proponents shove snippets of code under each other's >nose saying 'I bet you can't guess what this does!'" > As opposed to presenting reams of code, which, although with full explanations, the function of which can probably only be taken on faith? Given equivalent functionality, I would rather have a hope of understanding a snippet as opposed to a volume. -- |\/| Randy A MacDonald | Bring me... BLUE PAGES!!!! |\\| randy@godin.on.ca | BSc(Math) UNBF '83 | APL: If you can say it, it's done. Natural Born APL'er | *** GLi Info: info@godin.on.ca *** | Also http://www.godin.on.ca/randy ------------------------------------------------<-NTP>----{ gnat }- ^ permalink raw reply [flat|nested] 147+ messages in thread
[parent not found: <01bcdad2$fa9fdf60$25a43a91@basil.omroep.nl>]
* Re: Programming language vote - results [not found] ` <01bcdad2$fa9fdf60$25a43a91@basil.omroep.nl> @ 1997-10-17 0:00 ` D'Arcy J.M. Cain 0 siblings, 0 replies; 147+ messages in thread From: D'Arcy J.M. Cain @ 1997-10-17 0:00 UTC (permalink / raw) Jan Karman wrote: > > My favourite quote about APL - "I refuse to use any computer language > > in which the proponents shove snippets of code under each other's > > nose saying 'I bet you can't guess what this does!'" > > > > There are millions of kids who can read a music score. > For a lot of people it looks like a Jackson Pollock painting. Uh, OK. The quote suggested an interaction between people who understood the language. Certainly I don't expect to be able to show any program to someone who doesn't know the language (say mooreon and C for example) and have them understand it. It was a joke, son. Even APL programmers usually find it humorous. -- D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner. ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-15 0:00 ` Alan E & Carmel J Brain 1997-10-15 0:00 ` D'Arcy J.M. Cain @ 1997-10-17 0:00 ` Robert I. Eachus 1 sibling, 0 replies; 147+ messages in thread From: Robert I. Eachus @ 1997-10-17 0:00 UTC (permalink / raw) In article <34458CE3.507C@dynamite.com.au> Alan E & Carmel J Brain <aebrain@dynamite.com.au> writes: > I guess I'm probably the only contributor here whose preferred language > is Ada-95, and who has used a lot of APL in the commercial environment. Guess again... APL Is great for what it does, and you can do things in it, in a few lines, that take doezens or hundreds of pages in other languages. However, it takes just as long to understand the code. I even have code prototyped as a dozen lines of APL that eventually became about 25 pages of well structured, well commented Ada 83. (The Ada, of course, runs much faster, and that is not something I could have done in APL--I had to write a sparse matrix package tuned to the particular application.) In any case I wouldn't make any changes in either version without several weeks to refamiliarize myself with the algorithms and code. (And, yes the documentation outbulks by far either source version.) But I couldn't have written the code without the freedom granted by Ada, APL, and Lisp to redefine the things at one level, and work with the higher level abstract ONLY in other parts of the code. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott 1997-10-12 0:00 ` Jack Rudd 1997-10-13 0:00 ` David Ness @ 1997-10-13 0:00 ` Matthew Heaney 1997-10-14 0:00 ` Gary L. Scott 1997-10-13 0:00 ` Robert S. White 3 siblings, 1 reply; 147+ messages in thread From: Matthew Heaney @ 1997-10-13 0:00 UTC (permalink / raw) In article <343FD05C.8986A557@flash.net>, scottg@flash.net wrote: >Oh the horror stories about Ada just about anyone in the defense >industry could tell you...(inefficiency, bloat, development delays, >budget overruns)...I dare you to fit a Jovial application that already >max's out a computer's capabilities in the same box using OO techniques >in Ada...In fact, multiply memory and CPU throughput by 10 and try it. >You will likely be forced to back off OO quite a bit, making an even >bigger mess of maintainability/reusability... This statement is obviously incorrect, as Ada's OO facilities are actually quite efficient. A type for which inheritance is available - in Ada, a "tagged" type (called a "class" in other languages) - only requires 1 extra memory word to store the tag, and primitive operations (called "methods" in other languages) are bound statically by default. I have been happily programming in Ada for 10 years - by choice - but sorry to say have no "horror stories" to share with you, since my experience in Ada has only been pleasant. It may seem too fantastic to be true :-), but there are actually real Ada "success" stories! Visit the Ada home page for a list, to get a healthy dose of reality. <http://www.adahome.com> If you'd like to learn Ada, so you can avoid making vacuous comments about a language you know nothing about, you can get a free, high-quality Ada compiler, GNAT, at NYU. <ftp://ftp.cs.nyu.edu/gnat> -------------------------------------------------------------------- Matthew Heaney Software Development Consultant <mailto:matthew_heaney@acm.org> (818) 985-1271 ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` Matthew Heaney @ 1997-10-14 0:00 ` Gary L. Scott 0 siblings, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-14 0:00 UTC (permalink / raw) I guess I should clarify. The comment was not specifically about Ada, but about inappropriate use of "OO" analysis and design to produce unworkable code. These are far from vacuous comments. Matthew Heaney wrote: > In article <343FD05C.8986A557@flash.net>, scottg@flash.net wrote: > > >Oh the horror stories about Ada just about anyone in the defense > >industry could tell you...(inefficiency, bloat, development delays, > >budget overruns)...I dare you to fit a Jovial application that > already > >max's out a computer's capabilities in the same box using OO > techniques > >in Ada...In fact, multiply memory and CPU throughput by 10 and try > it. > >You will likely be forced to back off OO quite a bit, making an even > >bigger mess of maintainability/reusability... > > This statement is obviously incorrect, as Ada's OO facilities are > actually > quite efficient. A type for which inheritance is available - in Ada, > a > "tagged" type (called a "class" in other languages) - only requires 1 > extra > memory word to store the tag, and primitive operations (called > "methods" in > other languages) are bound statically by default. > > I have been happily programming in Ada for 10 years - by choice - but > sorry > to say have no "horror stories" to share with you, since my experience > in > Ada has only been pleasant. > > It may seem too fantastic to be true :-), but there are actually real > Ada > "success" stories! Visit the Ada home page for a list, to get a > healthy > dose of reality. > > <http://www.adahome.com> > > If you'd like to learn Ada, so you can avoid making vacuous comments > about > a language you know nothing about, you can get a free, high-quality > Ada > compiler, GNAT, at NYU. > > <ftp://ftp.cs.nyu.edu/gnat> > > -------------------------------------------------------------------- > Matthew Heaney > Software Development Consultant > <mailto:matthew_heaney@acm.org> > (818) 985-1271 -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott ` (2 preceding siblings ...) 1997-10-13 0:00 ` Matthew Heaney @ 1997-10-13 0:00 ` Robert S. White 1997-10-13 0:00 ` Gary L. Scott 3 siblings, 1 reply; 147+ messages in thread From: Robert S. White @ 1997-10-13 0:00 UTC (permalink / raw) In article <343FD05C.8986A557@flash.net>, scottg@flash.net says... > >Oh the horror stories about Ada just about anyone in the defense >industry could tell you...(inefficiency, bloat, development delays, >budget overruns)...I dare you to fit a Jovial application that already >max's out a computer's capabilities in the same box using OO techniques >in Ada. I bounce between Jovial (worse yet J73/I) and Ada all the time at work. Yes _some_compiler implementations are not as good as others - but others are just fine. Ever look at the code quality of Tartan Ada? Don't blame the language when coders go OO beserk. In _real_life_ we watch our processor utilization carefully and use pragma inline and turn off runtime checks in the "hot spot" code routines. You _can_ use Stucture Analysis with Ada to come up with an equivalent software design just like you used to get with Jovial. But it is so much easier to maintain and modify software that is designed with an object oriented (or at least object based) high level structure. You do have to know when to stop at low level routines, have to watch out for inefficiencies from virtual dispatching (avoid late binding), heap usage, and subroutine nesting. But the problem you describe with an already "max'd out" application written in Jovial (or C) using older Structure Analysis/(functional decomposition), would also have problems if you used any other OO capable language (C++, Eiffel, Delphi, etc.) and OOA/OOD without concern for processor utilization. >..In fact, multiply memory and CPU throughput by 10 and try it. I have seen an Ada implementation take about 10 - 15% more (1.1x to 1.15x) than a very mature (very efficient code) J73/I compiler on same processor target when equivalent compiler switches thrown. Never - never have I seen a 10x case due to the compilers alone. Even way back in 1984 with early immature compilers worse case max was 3x. Did your compiler that you are complaining about even have peephole optimization? >You will likely be forced to back off OO quite a bit, making an even >bigger mess of maintainability/reusability... And the original Jovial was wonderful in those areas? _____________________________________________________________________ Robert S. White -- An embedded systems software engineer e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results 1997-10-13 0:00 ` Robert S. White @ 1997-10-13 0:00 ` Gary L. Scott 0 siblings, 0 replies; 147+ messages in thread From: Gary L. Scott @ 1997-10-13 0:00 UTC (permalink / raw) Sorry, this is a little off-topic... Robert S. White wrote: > In article <343FD05C.8986A557@flash.net>, scottg@flash.net says... > > > >Oh the horror stories about Ada just about anyone in the defense > >industry could tell you...(inefficiency, bloat, development delays, > >budget overruns)...I dare you to fit a Jovial application that > already > >max's out a computer's capabilities in the same box using OO > techniques > >in Ada. > > I bounce between Jovial (worse yet J73/I) and Ada all the time at > work. Yes _some_compiler implementations are not as good as others - > but others are just fine. Ever look at the code quality of Tartan > Ada? > Don't blame the language when coders go OO beserk. In _real_life_ we > watch our processor utilization carefully and use pragma inline and > turn > off runtime checks in the "hot spot" code routines. You _can_ use > Stucture Analysis with Ada to come up with an equivalent software > design > just like you used to get with Jovial. But it is so much easier to > maintain and modify software that is designed with an object oriented > (or > at least object based) high level structure. You do have to know when > to > stop at low level routines, have to watch out for inefficiencies from > virtual dispatching (avoid late binding), heap usage, and subroutine > nesting. Of course, this was partly a problem of "design philosophy". The problem was that they didn't seem to know when to stop in the low level routines. But they eventually found a happy medium. Spent a lot of money doing so though. > > > But the problem you describe with an already "max'd out" application > > written in Jovial (or C) using older Structure Analysis/(functional > decomposition), would also have problems if you used any other OO > capable language (C++, Eiffel, Delphi, etc.) and OOA/OOD without > concern > for processor utilization. That was my point. "OO" not Ada specifically. By the time the project is over, the hardware will be obsolete (actually already is in terms of commercial products (CPU speed anyway)). So the schedule has basically extended beyond what was originally intended as the middle of its life span with no product in sight, lots of money spent. We could have just rehosted the JOVIAL and saved schedule, money, and had significantly more reserve in the computer at completion. > > > >..In fact, multiply memory and CPU throughput by 10 and try it. > > I have seen an Ada implementation take about 10 - 15% more (1.1x to > 1.15x) > than a very mature (very efficient code) J73/I compiler on same > processor target when equivalent compiler switches thrown. Never - > never > have I seen a 10x case due to the compilers alone. Even way back in > 1984 > with early immature compilers worse case max was 3x. Did your > compiler that you are complaining about even have peephole > optimization? Well, early on they had to turn off optimization in order to figure out why nothing was working. To be fair there were significant hardware problems as well that had to be worked around in software. > > > >You will likely be forced to back off OO quite a bit, making an even > >bigger mess of maintainability/reusability... > > And the original Jovial was wonderful in those areas? Depends a little on your point of view and the design of the code. The JOVIAL code is a lot easier to read/understand than the Ada code. This by itself can lead to advantages in terms of maintenance. We have been able to create very "modular" JOVIAL code which can essentially be dropped in/taken out with little impact to other functions. This is as valid of an approach as true "OO" in many cases. _____________________________________________________________________ > Robert S. White -- An embedded systems software engineer > e-mail reply to reverse of: ia us lib cedar-rapids crpl shift2 whiter -- Gary L. Scott scottg@flash.net ^ permalink raw reply [flat|nested] 147+ messages in thread
* Re: Programming language vote - results [not found] <343fbb5a.0@news.iprolink.ch> 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott @ 1997-10-19 0:00 ` William Rapp 1 sibling, 0 replies; 147+ messages in thread From: William Rapp @ 1997-10-19 0:00 UTC (permalink / raw) wEl@yddraiggoch.demon.co.uk> <34481248.4F0A@dynamite.com.au> Organization: CRL Network Services (415) 705-6060 [Login: guest] Distribution: In comp.lang.c Alan E & Carmel J Brain <aebrain@dynamite.com.au> wrote: Did you remember to make all the variables using only '1' 'I' 'O' '0'. ^ permalink raw reply [flat|nested] 147+ messages in thread
end of thread, other threads:[~1998-09-10 0:00 UTC | newest] Thread overview: 147+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <343fbb5a.0@news.iprolink.ch> 1997-10-11 0:00 ` Programming language vote - results Gary L. Scott 1997-10-12 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott 1997-10-13 0:00 ` safetran 1997-10-13 0:00 ` FRS DES 1997-10-13 0:00 ` Jack Rudd 1997-10-14 0:00 ` Philip Brashear 1997-10-14 0:00 ` Gary L. Scott 1997-10-13 0:00 ` Robert Munck 1997-10-13 0:00 ` Jack Rudd 1997-10-13 0:00 ` Gary L. Scott [not found] ` <3442B745.5352@lmco.com> 1997-10-15 0:00 ` Gary L. Scott 1997-10-16 0:00 ` James Giles 1997-10-16 0:00 ` Andrew Haley 1997-10-13 0:00 ` David Ness 1997-10-14 0:00 ` Randy MacDonald 1997-10-14 0:00 ` Jan Karman 1997-10-15 0:00 ` Alan E & Carmel J Brain 1997-10-15 0:00 ` D'Arcy J.M. Cain 1997-10-15 0:00 ` FRS DES 1997-10-15 0:00 ` Mark Stephen 1997-10-17 0:00 ` Randy MacDonald 1997-10-16 0:00 ` Alan E & Carmel J Brain 1997-10-16 0:00 ` FRS DES 1997-10-17 0:00 ` Jerry van Dijk 1997-10-16 0:00 ` John Sullivan 1997-10-17 0:00 ` Randy MacDonald 1997-10-17 0:00 ` Alan E & Carmel J Brain 1997-10-17 0:00 ` John Sullivan 1997-10-17 0:00 ` Randy MacDonald 1997-10-20 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` FRS DES 1997-10-21 0:00 ` Alan E & Carmel J Brain 1997-10-20 0:00 ` Lawrence Kirby 1997-10-20 0:00 ` Kaz 1997-10-21 0:00 ` Alan E & Carmel J Brain 1997-10-23 0:00 ` Ada Readability (Re: Programming language vote - results) Ray Blaak 1997-10-21 0:00 ` Programming language vote - results Alan E & Carmel J Brain 1997-10-21 0:00 ` Randy MacDonald 1997-10-22 0:00 ` Don Guinn [not found] ` <01bce1bf$5c2baaa0$95b66bcf@dkelly.ark.com> 1997-10-29 0:00 ` FRS DES 1997-10-29 0:00 ` Don Guinn 1997-10-29 0:00 ` Shmuel (Seymour J.) Metz 1997-10-31 0:00 ` Documenting Code (was:Programming language vote - results) Alan E & Carmel J Brain 1997-10-30 0:00 ` Charles Lin 1997-10-30 0:00 ` James L. Ryan 1997-10-31 0:00 ` Robert Bernecky 1997-10-31 0:00 ` Robert Bernecky 1997-11-01 0:00 ` Randy MacDonald 1997-11-01 0:00 ` Robert Dewar 1997-11-03 0:00 ` Jon S Anthony 1997-10-29 0:00 ` Programming language vote - results Randy MacDonald 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-26 0:00 ` functionality of Java (was Re: Programming language vote - results) Randy MacDonald 1997-10-23 0:00 ` Programming language vote - results Jack Rudd 1997-10-25 0:00 ` Alan E & Carmel J Brain 1997-10-25 0:00 ` Kaz 1997-10-26 0:00 ` FRS DES 1997-10-27 0:00 ` Robert Bernecky 1997-10-27 0:00 ` APL argument W. Wesley Groleau x4923 1997-10-28 0:00 ` Randy MacDonald 1997-10-28 0:00 ` Programming language vote - results Jan Karman 1997-10-28 0:00 ` Robert Bernecky 1997-10-28 0:00 ` James L. Ryan 1997-10-29 0:00 ` Robert Bernecky [not found] ` <bosworth-2910972044300001@access59.accsyst.com> 1997-10-30 0:00 ` Robert Bernecky 1997-10-30 0:00 ` James L. Ryan 1997-10-31 0:00 ` Robert Bernecky 1997-10-31 0:00 ` James L. Ryan 1997-10-29 0:00 ` Jack Rudd 1997-10-25 0:00 ` Peter Seebach 1997-11-18 0:00 ` Ingemar Ragnemalm 1997-11-18 0:00 ` firewind 1997-11-18 0:00 ` Kevin Swan 1997-11-19 0:00 ` Alan E & Carmel J Brain 1997-11-18 0:00 ` Larry Elmore 1997-11-20 0:00 ` firewind 1997-11-19 0:00 ` Mike Smith 1997-11-19 0:00 ` Matt 1997-11-20 0:00 ` firewind [not found] ` <3474C71B.536B12F6@cgocable.net> 1997-11-21 0:00 ` CVigue 1997-11-23 0:00 ` Lawrence Kirby 1997-11-24 0:00 ` FRS DES 1997-11-20 0:00 ` Coding for Obscurity Alan E & Carmel J Brain 1997-11-20 0:00 ` Stephan Wilms 1997-11-21 0:00 ` Jos A. Horsmeier 1997-11-23 0:00 ` Al Christians 1997-11-23 0:00 ` Alex Krol 1997-11-24 0:00 ` Jim Johnson 1997-11-24 0:00 ` Mark Wilden 1997-11-26 0:00 ` Robert S. White 1997-11-26 0:00 ` Miguel Carrasquer Vidal 1997-12-01 0:00 ` ISONE 1997-12-01 0:00 ` ISONE 1997-11-26 0:00 ` Mark Wilden 1997-11-26 0:00 ` Leon Jones 1997-11-26 0:00 ` Lawrence Kirby 1997-11-26 0:00 ` Ron Natalie 1997-11-27 0:00 ` Joerg Rodemann 1997-11-27 0:00 ` Richard A. O'Keefe 1997-11-24 0:00 ` Richard A. O'Keefe 1997-11-24 0:00 ` Matt 1997-11-24 0:00 ` Ed Falis 1997-11-24 0:00 ` Samuel T. Harris 1997-11-24 0:00 ` Jon S Anthony 1997-11-25 0:00 ` Samuel T. Harris 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Jos A. Horsmeier 1997-11-20 0:00 ` Programming language vote - results Andy Knight 1997-11-20 0:00 ` firewind 1997-11-20 0:00 ` Terry Richards 1997-11-20 0:00 ` Andy Knight 1997-11-23 0:00 ` Alex Krol 1997-11-25 0:00 ` William Tanksley 1997-11-26 0:00 ` Ron Natalie 1997-11-27 0:00 ` William Tanksley 1997-11-27 0:00 ` Lawrence Kirby [not found] ` <65keij$mkd$1@nerd.apk.net> 1997-11-27 0:00 ` Kaz Kylheku 1997-11-28 0:00 ` Shmuel (Seymour J.) Metz 1997-12-01 0:00 ` FRS DES 1997-11-18 0:00 ` Kevin Swan 1997-11-29 0:00 ` Ingemar Ragnemalm 1998-09-10 0:00 ` Steven Katz 1997-11-18 0:00 ` Lawrence Kirby 1997-11-24 0:00 ` Martin M Dowie 1997-11-25 0:00 ` Mark Wilden 1997-11-25 0:00 ` Martin M Dowie 1997-11-26 0:00 ` Lawrence Kirby 1997-11-26 0:00 ` FRS DES 1997-11-25 0:00 ` Kaz Kylheku 1997-11-26 0:00 ` Peter Seebach 1997-12-02 0:00 ` ANDREAS LEITNER 1997-12-02 0:00 ` Lawrence Kirby 1997-12-03 0:00 ` Billy Chambless 1997-12-03 0:00 ` Robert Dewar 1997-12-02 0:00 ` Robert Dewar 1997-12-05 0:00 ` John Sullivan 1997-11-19 0:00 ` Peter Seebach 1997-11-19 0:00 ` Alan E & Carmel J Brain 1997-10-16 0:00 ` Randy MacDonald [not found] ` <01bcdad2$fa9fdf60$25a43a91@basil.omroep.nl> 1997-10-17 0:00 ` D'Arcy J.M. Cain 1997-10-17 0:00 ` Robert I. Eachus 1997-10-13 0:00 ` Matthew Heaney 1997-10-14 0:00 ` Gary L. Scott 1997-10-13 0:00 ` Robert S. White 1997-10-13 0:00 ` Gary L. Scott 1997-10-19 0:00 ` William Rapp
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox