From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8de7eedad50552f1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!newsprint.newsread.com!newsfeed.stueberl.de!uucp.gnuu.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada bench : count words Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <87vf7n5njs.fsf@code-hal.de> <423f5813$0$9224$9b4e6d93@newsread4.arcor-online.net> <18arnvu705ly4$.1wz6ybz1jt70y$.dlg@40tude.net> <1q9cx4jt7802s.k45m6mcntl87$.dlg@40tude.net> <460oxs2p0hbc.yjqxjeasx37r.dlg@40tude.net> <1spfhtlo4ya1w.1a8leo0bqclk8.dlg@40tude.net> Date: Mon, 28 Mar 2005 22:56:16 +0200 Message-ID: <19eg4oytj672x$.1a77nseftvkzk$.dlg@40tude.net> NNTP-Posting-Date: 28 Mar 2005 22:56:16 MEST NNTP-Posting-Host: 7971d832.newsread4.arcor-online.net X-Trace: DXC=PT56bCOgUkn_?_Y?LUEPKAmD8U< X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:10094 Date: 2005-03-28T22:56:16+02:00 List-Id: On Mon, 28 Mar 2005 21:54:32 +0200, jtg wrote: > Dmitry A. Kazakov wrote: > >>>IMHO the challenge is OK. Look at the system commands (in UNIX). In >>>many cases text I/O performance is crucial. But since >>>existing commands are very fast, nobody even thinks about it. >> >> Ah, you hit my sore spot! In my view this is the problem of bad design. It >> is characteristic of UNIX which said has three mouse drives, one per >> button, but only for UNIX. [ The famous idea of splitting an application >> into a chain of tiny commands like wc, sort etc is attractive but >> altogether wrong. There is no universal way to do it. Then what about pipes >> overhead and need of multiple re-scans. I don't buy it, and scripting >> languages too. ] > It depends on what you are doing. Maybe you just didn't encounter > problems that needed scripting languages or pipe chain. > From my own experience I remember a tiny awk script I assisted to > create, which needed a minute to automatically perform a task > that usually took one day of human-assisted work with office > tools. It took several minutes to create the script itself. I write such things in Ada. I am too stupid to understand bash man pages. Cryptography isn't my strength. Then when something does not work as expected, it takes hours before I can find the problem, usually a pretty idiotic one, which would never happen if it was written in something more advanced than mumbling. All that is just in vain. > "Office people" then looked at it and spent some time to create > "office interface" in VB, that was just GUI for the script. > They didn't even think of writing its contents in VB. And if they > did, it would take several days to create, test and remove > bugs from the program (integrated awk, diff and several > other functions, and file I/O too). > The way wc and other UNIX commands cooperate is briliant, Maybe, but I just don't need wc! There is no occupation "word counting". The most close thing is linguistics and text analysis. Can wc that? > it is the > right way to do certain things and it does not exclude other ways > of solving other problems. If you need Office, you can run it, even > on UNIX. What's the problem? The problem is that there are 1000 different commands with 50 options each, which gives 1000*2**50 variants to remember. Every UNIX admin starts with making an alias to ls and 100 further commands. It is just unusable. It took decades before people finally understood it and wrote KDE, Gnome control centers. Admins despise them, but they are lost. >> If you are a paying customer of ACT, you can try... (:-)) >> > No. I was just fascinated with all the efforts shown in this thread. :-) I think we have tolerated that C guys telling us that Ada is slow for too long time. Game is over! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de