Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #9626 > unrolled thread

Re: C is not a low level language

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 12:40 +0800
    Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 05:16 +0000
      Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:20 +0800
        Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 13:24 +0800
        Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-24 19:45 +0800
        Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 13:09 +0000
          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:38 +0000
            Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 15:18 +0000
              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 17:21 +0100
                Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:43 +0000
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:17 +0100
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 20:02 +0100
                    Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 19:26 +0000
                      Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-24 21:36 +0100
                        Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 20:47 +0000
                          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:10 +0000
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:25 +0100
                            Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:24 +0000
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 17:04 +0100
                                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 16:52 +0000
                        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 17:59 -0800
                        Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 08:46 +0100
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:36 +0100
                            Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 10:13 +0100
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-26 09:56 +0100
                            Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-25 14:12 +0000
                          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:20 +0000
                            Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:36 -0800
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:29 +0200
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 09:41 +0100
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:55 +0200
                              Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:24 +0100
                    Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:03 +0000
                      Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:58 +0100
                        Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-25 09:40 +0100
                          Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 10:01 +0100
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:55 -0800
                  Re: C is not a low level language "R.Wieser" <address@not.available> - 2019-02-25 08:31 +0100
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 17:42 +0000
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:19 +0000
              Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-24 17:56 +0000
                Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-24 18:23 +0000
                  Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:58 +0000
                Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 20:52 +0000
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:31 +0000
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 14:01 -0800
                  Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 23:04 +0000
                    Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 15:53 -0800
                    Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:07 +0000
                Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 20:50 +0100
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:04 +0000
                    Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-28 16:25 +0000
                      Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-28 11:56 -0500
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-28 19:45 +0000
                Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 17:55 +0000
                  Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-28 16:03 +0000
                    Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 11:25 -0800
                      Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-28 19:30 +0000
            Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:47 +0000
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 21:29 +0000
                Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-25 20:16 +0000
        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 12:53 -0800
        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 09:49 +0200
      Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:07 +0100
        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 22:59 +0000
          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 09:57 +0100
            Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 09:59 +0000
    Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 19:54 +1300
      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 07:56 +0000
        Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-02-24 21:58 +1300
          Re: C is not a low level language "A. Dumas" <alexandre@dumas.fr.invalid> - 2019-02-24 10:57 +0100
          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:13 +0000
          Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 10:47 +0000
            Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:48 -0500
              Re: C is not a low level language The Natural Philosopher <tnp@invalid.invalid> - 2019-02-24 14:42 +0000
              Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 07:15 +0000
                Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:25 -0500
                  Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:03 +0000
                    Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 12:10 -0500
                      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 17:58 +0000
                  Re: C is not a low level language Axel Berger <Spam@Berger-Odenthal.De> - 2019-02-25 17:44 +0100
                    Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:18 +0200
              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 10:35 +0200
                Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:44 +0000
                  Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-02-25 12:29 +0000
                    Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 14:26 +0000
                      Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:08 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:08 +0200
                        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 18:00 +0000
                      Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-27 22:37 -0800
                        Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-28 02:25 -0800
                  Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 12:27 +0000
                Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-25 09:36 -0500
                  Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 15:05 +0000
                    Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 19:20 +0200
                      Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-25 23:02 +0000
                        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:41 +0200
                          Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 12:20 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 14:01 +0100
                          Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-26 08:48 -0500
                          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-26 19:20 +0100
                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:04 -0500
          Re: C is not a low level language lonelydad <lonelydad58@gmail.com> - 2019-02-24 14:44 +0000
          Re: C is not a low level language "U-laptop\\Norah" <Norah@laptop.i-did-not-set--mail-host-address--so-tickle-me> - 2019-02-27 16:16 -0600
            Re: C is not a low level language Eric Stevens <eric.stevens@sum.co.nz> - 2019-03-01 12:12 +1300
              Re: C is not a low level language Richard Heathfield <rjh@cpax.org.uk> - 2019-03-01 00:19 +0000
        Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 19:59 -0800
          Re: C is not a low level language Bill Findlay <findlaybill@blueyonder.co.uk> - 2019-02-25 16:10 +0000
          Re: C is not a low level language Björn Lundin <b.f.lundin@gmail.com> - 2019-02-25 21:02 +0100
            Re: C is not a low level language Lars Enderin <lars.enderin@telia.com> - 2019-02-26 00:37 +0100
              Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 19:09 -0500
              Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-26 06:52 +0000
      Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:30 -0800
        Re: C is not a low level language T <T@invalid.invalid> - 2019-02-24 00:31 -0800
        Re: C is not a low level language Ahem A Rivet's Shot <steveo@eircom.net> - 2019-02-24 10:16 +0000
      Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 11:22 +0000
        Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 08:51 -0500
          Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 07:20 -0800
            Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-24 15:35 +0000
              Re: C is not a low level language "Mayayana" <mayayana@invalid.nospam> - 2019-02-24 11:05 -0500
              Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:39 -0800
                Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-24 19:11 -0800
                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 09:41 -0500
                  Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 14:53 +0000
                    Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 10:19 -0500
                      Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-25 16:38 +0100
                        Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-25 11:20 -0500
                          Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 17:49 +0000
                            Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:18 +0100
                        Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                          Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:25 +0200
                            Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
                              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:45 +0200
                                Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
                                Re: C is not a low level language Wolf K <wolfmac@sympatico.ca> - 2019-02-26 09:11 -0500
                            Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:23 +0100
                            Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-26 08:02 -0500
                              Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 17:57 +0200
                          Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                        Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 17:42 -0500
                        Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 22:33 +0000
                          Re: C is not a low level language David Brown <david.brown@hesbynett.no> - 2019-02-26 09:30 +0100
                      Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                      Re: C is not a low level language Keith Thompson <kst-u@mib.org> - 2019-02-25 13:52 -0800
                    Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 15:20 +0000
                      Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
                        Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:47 +0000
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:50 -0500
                            Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-25 18:59 +0000
                        Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-25 20:15 +0200
                          Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-25 18:38 +0000
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:49 +0200
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:40 -0500
                            Re: C is not a low level language Wouter Verhelst <w@uter.be> - 2019-02-26 12:55 +0200
                              Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 16:29 +0000
                                Re: C is not a low level language Diesel <nobody@haph.org> - 2019-03-05 04:29 +0000
                                  Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-03-04 23:43 -0500
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 18:16 +0000
                        Re: C is not a low level language "NY" <me@privacy.net> - 2019-02-25 17:44 +0000
                          Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 13:05 -0500
                            Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 00:51 -0600
                              Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 10:58 +0100
                                Re: C is not a low level language Robert Wessel <robertwessel2@yahoo.com> - 2019-02-26 10:53 -0600
                                  Re: C is not a low level language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-02-26 17:49 +0000
                                  Re: C is not a low level language scott@slp53.sl.home (Scott Lurndal) - 2019-02-26 18:11 +0000
                                    Re: C is not a low level language Bart <bc@freeuk.com> - 2019-02-26 18:24 +0000
                                  Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:24 +0100
                                    Re: C is not a low level language "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-02-26 19:44 +0100
                        Re: C is not a low level language nobody@example.org (Scott) - 2019-02-26 06:33 +0000
                    Re: C is not a low level language nospam <nospam@nospam.invalid> - 2019-02-25 12:17 -0500
          Re: C is not a low level language Gene Wirchenko <genew@telus.net> - 2019-02-24 20:03 -0800
        Re: C is not a low level language pyotr filipivich <phamp@mindspring.com> - 2019-02-24 14:56 -0800
    Re: C is not a low level language Jasen Betts <jasen@xnet.co.nz> - 2019-02-24 20:43 +0000
      Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 14:14 +0800
        Re: C is not a low level language "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> - 2019-02-25 10:45 +0000
          Re: C is not a low level language "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2019-02-25 19:04 +0800

Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]

#9818

In article <XnsAA08EFC8FEB41HT1@doCX0.74.zmu4y91>, Diesel
<nobody@haph.org> wrote:

> > Windows desktop applications aren't the whole world, you know.
> 
> nospam doesn't, afaik, write windows desktop applications.

not currently, but i have in the past. 

> They write 
> apps for Apple based products. cell phones primarily I believe, in a 
> scripting language. 

not even close to correct, and not even possible, given that both
android and ios apps are not written in a scripting language.

> So...I dunno what level of programmer or coder 
> you'd actually consider the individual to be.

a rather successful one.

[toc] | [prev] | [next] | [standalone]

#9736

"nospam" <nospam@nospam.invalid> wrote in message 
news:250220191305329065%nospam@nospam.invalid...
> In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY
> <me@privacy.net> wrote:
>
>> >> but I know that the Z80 routine was
>> >> several orders of magnitude faster than the same algorithm in 
>> >> interpreted
>> >> BASIC and several times faster than a compiled Pascal program with the
>> >> same
>> >> algorithm.
>> >
>> > that just means the compiler wasn't any good.
>> >
>> > yep, and it's *really* hard to beat a modern compiler
>>
>> The compiler in question was Turbo Pascal of mid- to late-1980s vintage,
>> running on a Z80 under CP/M 3. I'm not sure how efficient that was.
>
> that's not a modern compiler nor a modern processor either.

Exactly. I imagine that a modern compiler and processor may achieve a result 
which was closer to the native assembly language for that processor.

>> As you
>> say, modern compilers may well be more efficient - but they may also 
>> bloat
>> the code with code that was never actually called but was compiled in
>> nevertheless ;-)
>
> they don't, but even if that were true, code that is not called can't
> slow anything down.

I was using "efficient" in both senses - both in terms of speed and in terms 
of small executable size.

> bubble sort is very easy to write, it's just not fast.

Is it any quicker if alternate passes are in opposite directions, to make 
the largest number bubble to the top and then the smallest number bubble to 
the bottom? As long as in both cases you stop the loop one number 
less/greater than you did last time to exclude testing the number that is 
now at the top/bottom of the list. 

[toc] | [prev] | [next] | [standalone]

#9749

"nospam" <nospam@nospam.invalid> wrote in message 
news:250220191217517376%nospam@nospam.invalid...
>> but I know that the Z80 routine was
>> several orders of magnitude faster than the same algorithm in interpreted
>> BASIC and several times faster than a compiled Pascal program with the 
>> same
>> algorithm.
>
> that just means the compiler wasn't any good.
>
> yep, and it's *really* hard to beat a modern compiler

The compiler in question was Turbo Pascal of mid- to late-1980s vintage, 
running on a Z80 under CP/M 3. I'm not sure how efficient that was. As you 
say, modern compilers may well be more efficient - but they may also bloat 
the code with code that was never actually called but was compiled in 
nevertheless ;-)

I should have tried to code a more efficient sort algorithm than bubble 
sort, to see how much improvement there was, but bubble is simple to 
remember (*) and to code, and I was doing it as a programming exercise 
rather than with a real-life application that needed the fastest sort 
available.


(*) I can remember it without needing to look it up every time, and I can 
visualise exactly what it's doing, whereas shell sorts start to make my 
brain hurt working out what they are doing ;-) 

[toc] | [prev] | [next] | [standalone]

#9757

In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY
<me@privacy.net> wrote:

> >> but I know that the Z80 routine was
> >> several orders of magnitude faster than the same algorithm in interpreted
> >> BASIC and several times faster than a compiled Pascal program with the 
> >> same
> >> algorithm.
> >
> > that just means the compiler wasn't any good.
> >
> > yep, and it's *really* hard to beat a modern compiler
> 
> The compiler in question was Turbo Pascal of mid- to late-1980s vintage, 
> running on a Z80 under CP/M 3. I'm not sure how efficient that was.

that's not a modern compiler nor a modern processor either.

> As you 
> say, modern compilers may well be more efficient - but they may also bloat 
> the code with code that was never actually called but was compiled in 
> nevertheless ;-)

they don't, but even if that were true, code that is not called can't
slow anything down. 

> I should have tried to code a more efficient sort algorithm than bubble 
> sort, to see how much improvement there was, but bubble is simple to 
> remember (*) and to code, and I was doing it as a programming exercise 
> rather than with a real-life application that needed the fastest sort 
> available.
>
> (*) I can remember it without needing to look it up every time, and I can 
> visualise exactly what it's doing, whereas shell sorts start to make my 
> brain hurt working out what they are doing ;-) 

bubble sort is very easy to write, it's just not fast.

[toc] | [prev] | [next] | [standalone]

#9765

On Mon, 25 Feb 2019 13:05:32 -0500, nospam <nospam@nospam.invalid>
wrote:

>In article <yL2dnUP1iNIStOnBnZ2dnUU78dnNnZ2d@brightview.co.uk>, NY
><me@privacy.net> wrote:
>
>> >> but I know that the Z80 routine was
>> >> several orders of magnitude faster than the same algorithm in interpreted
>> >> BASIC and several times faster than a compiled Pascal program with the 
>> >> same
>> >> algorithm.
>> >
>> > that just means the compiler wasn't any good.
>> >
>> > yep, and it's *really* hard to beat a modern compiler
>> 
>> The compiler in question was Turbo Pascal of mid- to late-1980s vintage, 
>> running on a Z80 under CP/M 3. I'm not sure how efficient that was.
>
>that's not a modern compiler nor a modern processor either.
>
>> As you 
>> say, modern compilers may well be more efficient - but they may also bloat 
>> the code with code that was never actually called but was compiled in 
>> nevertheless ;-)
>
>they don't, but even if that were true, code that is not called can't
>slow anything down. 
>
>> I should have tried to code a more efficient sort algorithm than bubble 
>> sort, to see how much improvement there was, but bubble is simple to 
>> remember (*) and to code, and I was doing it as a programming exercise 
>> rather than with a real-life application that needed the fastest sort 
>> available.
>>
>> (*) I can remember it without needing to look it up every time, and I can 
>> visualise exactly what it's doing, whereas shell sorts start to make my 
>> brain hurt working out what they are doing ;-) 
>
>bubble sort is very easy to write, it's just not fast.


Insertion sort is even easier to write.  And it's usually twice as
fast as bubble sort.

[toc] | [prev] | [next] | [standalone]

#9773

Robert Wessel <robertwessel2@yahoo.com> writes:

>>bubble sort is very easy to write, it's just not fast.
>
>
> Insertion sort is even easier to write.  And it's usually twice as
> fast as bubble sort.

Bubble sort is the fastest, on a vector already sorted. It's O(n) with
the best constants in this best case.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#9787

On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
<pjb@informatimago.com> wrote:

>Robert Wessel <robertwessel2@yahoo.com> writes:
>
>>>bubble sort is very easy to write, it's just not fast.
>>
>>
>> Insertion sort is even easier to write.  And it's usually twice as
>> fast as bubble sort.
>
>Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>the best constants in this best case.


I've heard that assertion multiple time, but have not seen much
evidence to back it up.  In some tests I've run over the years, bubble
sort and insertion sort on already sorted datasets tend to have
performance very nearly the same, if not identical, subject to
implementation vagaries.  If there is an advantage, it's very small.

Consider (MSVC, /Ox):

#include <windows.h>

#define ITER 1000000
#define SZ 10000
int a[SZ];

void bubblesort(int *a, int n)
{
   int i, j;

   for (j = 0; j<n; j++)
       {
       int swapped = 0;
       i = 0;
       while (i<n-1)
           {
           if (a[i] > a[i+1])
               {
               int temp = a[i];
               a[i] = a[i+1];
               a[i+1] = temp;
               swapped = 1;
               }
           i++;
           }

       if (!swapped)
           break;

       n--;
   }
}

void insertionsort(int *a, int n)
{
   int i, j;

   for (j = 1; j<n; j++)
       {
       i = j;
       while (i>0 && a[i] < a[i-1])
           {
           int temp = a[i];
           a[i] = a[i+1];
           a[i+1] = temp;
           i--;
           }
   }
}

int main()
{
   int i;
   DWORD starttick, elapsedtick;

   for (i=0; i<SZ; i++)
       a[i] = i;

   printf("Array size: %i, iterations: %i\n", SZ, ITER);

   starttick = GetTickCount();
   for (i=0; i<ITER; i++)
       bubblesort(a, SZ);
   elapsedtick = GetTickCount() - starttick;
   printf("Bubble sort: %.10fms/iter\n", (double)elapsedtick/ITER);

   starttick = GetTickCount();
   for (i=0; i<ITER; i++)
       bubblesort(a, SZ);
   elapsedtick = GetTickCount() - starttick;
   printf("Insertion sort: %.10fms/iter\n", (double)elapsedtick/ITER);

   return 0;
}


***


G:\wessel>test227
Array size: 10000, iterations: 1000000
Bubble sort: 0.0183590000ms/iter
Insertion sort: 0.0185160000ms/iter

G:\wessel>test227
Array size: 10000, iterations: 1000000
Bubble sort: 0.0182500000ms/iter
Insertion sort: 0.0180470000ms/iter

G:\wessel>test227
Array size: 10000, iterations: 1000000
Bubble sort: 0.0182650000ms/iter
Insertion sort: 0.0182500000ms/iter

[toc] | [prev] | [next] | [standalone]

#9788

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
> <pjb@informatimago.com> wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>>>bubble sort is very easy to write, it's just not fast.
>>>
>>>
>>> Insertion sort is even easier to write.  And it's usually twice as
>>> fast as bubble sort.
>>
>>Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>>the best constants in this best case.
>
> I've heard that assertion multiple time, but have not seen much
> evidence to back it up.  In some tests I've run over the years, bubble
> sort and insertion sort on already sorted datasets tend to have
> performance very nearly the same, if not identical, subject to
> implementation vagaries.  If there is an advantage, it's very small.
>
> Consider (MSVC, /Ox):
>
> #include <windows.h>
>
> #define ITER 1000000
> #define SZ 10000
> int a[SZ];
>
> void bubblesort(int *a, int n)
> {
>    int i, j;
>
>    for (j = 0; j<n; j++)
>        {
>        int swapped = 0;
>        i = 0;
>        while (i<n-1)
>            {
>            if (a[i] > a[i+1])
>                {
>                int temp = a[i];
>                a[i] = a[i+1];
>                a[i+1] = temp;
>                swapped = 1;
>                }
>            i++;
>            }
>
>        if (!swapped)
>            break;
>
>        n--;
>    }
> }
>
> void insertionsort(int *a, int n)
> {
>    int i, j;
>
>    for (j = 1; j<n; j++)
>        {
>        i = j;
>        while (i>0 && a[i] < a[i-1])
>            {
>            int temp = a[i];
>            a[i] = a[i+1];
>            a[i+1] = temp;
>            i--;
>            }
>    }
> }
>
> int main()
> {
>    int i;
>    DWORD starttick, elapsedtick;
>
>    for (i=0; i<SZ; i++)
>        a[i] = i;
>
>    printf("Array size: %i, iterations: %i\n", SZ, ITER);
>
>    starttick = GetTickCount();
>    for (i=0; i<ITER; i++)
>        bubblesort(a, SZ);
>    elapsedtick = GetTickCount() - starttick;
>    printf("Bubble sort: %.10fms/iter\n", (double)elapsedtick/ITER);
>
>    starttick = GetTickCount();
>    for (i=0; i<ITER; i++)
>        bubblesort(a, SZ);
>    elapsedtick = GetTickCount() - starttick;
>    printf("Insertion sort: %.10fms/iter\n", (double)elapsedtick/ITER);
>
>    return 0;
> }

When corrected to call insertion sort and "Linuxised" I find that,
un-optimised, bubble sort takes about 90% of the time taken by insertion
sort:

Array size: 10000, iterations: 1000000
Bubble sort:    23.776µs/iter
Insertion sort: 26.548µs/iter
Ratio: 0.896

This difference disappears when using gcc -O3:

Array size: 10000, iterations: 1000000
Bubble sort:    5.684µs/iter
Insertion sort: 5.681µs/iter
Ratio: 1.001

I've seen bubble sort written without the "stop when no swaps" flag but
that would hardly be a fair comparison.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#9789

Robert Wessel <robertwessel2@yahoo.com> writes:
>On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
><pjb@informatimago.com> wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>>>bubble sort is very easy to write, it's just not fast.
>>>
>>>
>>> Insertion sort is even easier to write.  And it's usually twice as
>>> fast as bubble sort.
>>
>>Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>>the best constants in this best case.
>
>
>I've heard that assertion multiple time, but have not seen much
>evidence to back it up.  In some tests I've run over the years, bubble
>sort and insertion sort on already sorted datasets tend to have
>performance very nearly the same, if not identical, subject to
>implementation vagaries.  If there is an advantage, it's very small.
>
>Consider (MSVC, /Ox):
>
>#include <windows.h>
>
>#define ITER 1000000
>#define SZ 10000
>int a[SZ];
>

Ok, now try it with a dataset that doesn't fit into the typical
L1D cache.   (e.g. #define SZ 10000000  // ~400MB).

[toc] | [prev] | [next] | [standalone]

#9791

On 26/02/2019 18:11, Scott Lurndal wrote:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
>> <pjb@informatimago.com> wrote:
>>
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>>> bubble sort is very easy to write, it's just not fast.
>>>>
>>>>
>>>> Insertion sort is even easier to write.  And it's usually twice as
>>>> fast as bubble sort.
>>>
>>> Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>>> the best constants in this best case.
>>
>>
>> I've heard that assertion multiple time, but have not seen much
>> evidence to back it up.  In some tests I've run over the years, bubble
>> sort and insertion sort on already sorted datasets tend to have
>> performance very nearly the same, if not identical, subject to
>> implementation vagaries.  If there is an advantage, it's very small.
>>
>> Consider (MSVC, /Ox):
>>
>> #include <windows.h>
>>
>> #define ITER 1000000
>> #define SZ 10000
>> int a[SZ];
>>
> 
> Ok, now try it with a dataset that doesn't fit into the typical
> L1D cache.   (e.g. #define SZ 10000000  // ~400MB).
> 

You have a typo so it's not clear if you mean 10M items or 100M.

But with either, timings are pretty much identical, unoptimised. 
Optimised, bubble sort is still ahead.

However, nobody would ever use bubble sort with N=1000, let along 10M or 
100M.

[toc] | [prev] | [next] | [standalone]

#9792

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
> <pjb@informatimago.com> wrote:
>
>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>
>>>>bubble sort is very easy to write, it's just not fast.
>>>
>>>
>>> Insertion sort is even easier to write.  And it's usually twice as
>>> fast as bubble sort.
>>
>>Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>>the best constants in this best case.
>
>
> I've heard that assertion multiple time, but have not seen much
> evidence to back it up.  In some tests I've run over the years, bubble
> sort and insertion sort on already sorted datasets tend to have
> performance very nearly the same, if not identical, subject to
> implementation vagaries.  If there is an advantage, it's very small.

bubblesort still uses less comparisons:
------------------------------------------------------------
#include <stdio.h>

int a[]={1,2,3,4,5,6,7,8,9,
    10,11,12,13,14,15,16,17,18,19};

int bubblesort(int *a, int n)
{
    int count=0;
    int i, j;

    for (j = 0; count++,j<n; j++)
    {
        int swapped = 0;
        i = 0;
        while (count++,i<n-1)
        {
            if (count++,a[i] > a[i+1])
            {
                int temp = a[i];
                a[i] = a[i+1];
                a[i+1] = temp;
                swapped = 1;
            }
            i++;
        }

        if (!swapped)
            break;

        n--;
    }
    return count;
}

int insertionsort(int *a, int n)
{
    int count=0;
    int i, j;

    for (j = 1; count++,j<n; j++)
    {
        i = j;
        while ((count++,i>0) && (count++,a[i] < a[i-1]))
        {
            int temp = a[i];
            a[i] = a[i+1];
            a[i+1] = temp;
            i--;
        }
    }
    return count;
}

int main()
{
    printf("bubblesort    = %5d comparisons\n",bubblesort(a, sizeof(a)/sizeof(a[0])));
    printf("insertionsort = %5d comparisons\n",insertionsort(a, sizeof(a)/sizeof(a[0])));
    return 0;
}
------------------------------------------------------------

-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Tue Feb 26 19:22:01

SRC="/Users/pjb/s.c" ; EXE="s" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} &&  ./${EXE} && echo status = $?
bubblesort    =    38 comparisons
insertionsort =    55 comparisons
status = 0

Compilation finished at Tue Feb 26 19:22:05

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#9793

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Tue, 26 Feb 2019 10:58:09 +0100, "Pascal J. Bourguignon"
>> <pjb@informatimago.com> wrote:
>>
>>>Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>>>bubble sort is very easy to write, it's just not fast.
>>>>
>>>>
>>>> Insertion sort is even easier to write.  And it's usually twice as
>>>> fast as bubble sort.
>>>
>>>Bubble sort is the fastest, on a vector already sorted. It's O(n) with
>>>the best constants in this best case.
>>
>>
>> I've heard that assertion multiple time, but have not seen much
>> evidence to back it up.  In some tests I've run over the years, bubble
>> sort and insertion sort on already sorted datasets tend to have
>> performance very nearly the same, if not identical, subject to
>> implementation vagaries.  If there is an advantage, it's very small.

Actually, the fun is with quicksort:

#include <stdio.h>

int a[]={1,2,3,4,5,6,7,8,9,
    10,11,12,13,14,15,16,17,18,19};

#define swap(a,b) do{int t=a;a=b;b=t;}while(0)

int quicksort_count=0;
int quicksort_calls=0;

int partition(int*a,int lo, int hi){
    int pivot=a[hi];
    int i=lo;
    int j;
    for(j=lo;quicksort_count++,j<hi-1;j++){
        if(quicksort_count++,a[j]<pivot){
            swap(a[i],a[j]);
            i++;}}
    swap(a[i],a[hi]);
    return i;}

void quicksort(int*a,int lo, int hi){
    if(quicksort_count++,lo<hi){
        int p=(quicksort_calls++,partition(a,lo,hi));
        quicksort_calls++,quicksort(a,lo,p-1);
        quicksort_calls++,quicksort(a,p+1,hi);}}
        
void qsort(int *a, int n){
    quicksort_count=0;
    quicksort_calls=1,quicksort(a,0,n-1);}


int bubblesort(int *a, int n)
{
    int count=0;
    int i, j;

    for (j = 0; count++,j<n; j++)
    {
        int swapped = 0;
        i = 0;
        while (count++,i<n-1)
        {
            if (count++,a[i] > a[i+1])
            {
                swap(a[i],a[i+1]);
                swapped = 1;
            }
            i++;
        }

        if (!swapped)
            break;

        n--;
    }
    return count;
}

int insertionsort(int *a, int n)
{
    int count=0;
    int i, j;

    for (j = 1; count++,j<n; j++)
    {
        i = j;
        while ((count++,i>0) && (count++,a[i] < a[i-1]))
        {
            swap(a[i],a[i+1]);
            i--;
        }
    }
    return count;
}

int main()
{
    printf("bubblesort    = %5d comparisons\n",bubblesort(a, sizeof(a)/sizeof(a[0])));
    printf("insertionsort = %5d comparisons\n",insertionsort(a, sizeof(a)/sizeof(a[0])));
    qsort(a, sizeof(a)/sizeof(a[0]));
    printf("quicksort     = %5d comparisons and very much worse, %5d calls\n",quicksort_count,quicksort_calls);
    return 0;
}

/*
-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Tue Feb 26 19:37:07

SRC="/Users/pjb/s.c" ; EXE="s" ; gcc -I. -L. -g3 -ggdb3 -o ${EXE} ${SRC} &&  ./${EXE} && echo status = $?
bubblesort    =    38 comparisons
insertionsort =    55 comparisons
quicksort     =   190 comparisons and very much worse,    28 calls
status = 0

Compilation finished at Tue Feb 26 19:37:07

*/

Function calls can easily be a hundred of times slower than a mere
comparison.  But even counting for the best, the function calls above
will have to write 5 words (the parameters, the link and the return
address at least), and read two words (the link and the return address),
plus the actual JSR, compared to two reads for a single comparison, so
at best it's 5 times slower than a comparison.  That gives at least 330
equivalent-comparison for quicksort, a 10x overhead in comparisons.  I
would say that the break even would cover quite a few swaps…

For arrays almost sorted, I'd really avoid quicksort.

-- 
__Pascal J. Bourguignon__
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#9764

On Mon, 25 Feb 2019 12:17:51 -0500, nospam <nospam@nospam.invalid>
wrote:

>In article <zoidnfqlAvoHmunBnZ2dnUU78L3NnZ2d@brightview.co.uk>, NY
><me@privacy.net> wrote:
>
>> When I was at university, doing electronic engineering, in the early 1980s, 
>> we did a bit of assembler programming, in 6809. Everyone was very frustrated 
>> at the choice of CPU because those who had their own computer had either a 
>> CP/M-based (Z80) or Commodore Pet (6502); no-one had a computer that used a 
>> 6809 that they could practice on out of hours. Of course, a few years later, 
>> 8086 and its successors (386, 486 etc) would have been fairly universal ;-) 
>> Nowadays they'd probably also teach RISC (eg SPARC and ARM) processors.
>
>their frustration was unfamiliarity and inability to learn new things.
>
>the 6809 was a *very* good processor, along with its successor, the
>68000 series,*far* easier to write code than the z80 and x86. 

My experiences ran in the other direction. I cut teeth on the 6809,
and when I was later exposed to the 80286 it was an abrupt shift in
perspective. I never played with the 6502 or Z80, it would have
irritated me at the time, but from this distance I think it would have
been valuable experience.

>> it working. I forget the actual timings, but I know that the Z80 routine was 
>> several orders of magnitude faster than the same algorithm in interpreted 
>> BASIC and several times faster than a compiled Pascal program with the same 
>> algorithm.
>
>that just means the compiler wasn't any good.

No surprise with BASIC, it was always a dog in those days.

Didn't some of the Pascal systems utilize a kind of byte code running
in a virtual executive? That might do it. I never noticed Pascal being
especially slower than equivalent C, but I never did anything very
demanding with it, and I might not have been using a p-code based
system anyway. Borland used to be a hell of a compiler shop.

[toc] | [prev] | [next] | [standalone]

#9726

In article <+BH$Xu6fFAdcFwF7@255soft.uk>, J. P. Gilliver (John)
<G6JPG-255@255soft.uk> wrote:

> About ten years ago, I was startled, speaking to a new graduate with a 
> computing degree, when he revealed that he'd NEVER DONE ANY ASSEMBLER. 

why is that surprising?

there's no need to write assembly anymore, with very, very rare
exception, such as writing a compiler.

> Thinking about it afterwards, I decided that the computing world is 
> certainly big enough that he'd have no difficulty in finding employment, 
> but it did throw me at the time; I'd come up through (7-bit serial then) 
> 8-bit, 6800 and 6502, then in professional life some work in bit-slice 
> processors (AMD 2901, 2960, etc., and the IDT copies thereof), where we 
> had to _create_ our assembly tools as we assembled our processors.

things are very, very, very different since then. extremely so.

> Maybe nowadays assembler is _rare_?

yes. almost nonexistent. see above for compiler.

[toc] | [prev] | [next] | [standalone]

#9679

On Sun, 24 Feb 2019 08:51:59 -0500, "Mayayana"
<mayayana@invalid.nospam> wrote:

>"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> wrote
>
>| Like all programming languages, it is possible to write something that's
>| indescribably elegant, and pleasing to the eye - but, as another has
>| said, virtually impossible to understand how it works when you come back
>| to it after a while.
>
>  That's a pet peeve of mine. People who think it's
>clever to shrink multiple steps into one. They sacrifice
>readability based on a misconception -- the notion
>that terse code is efficient code. 

     Or the notion that the code will never change.

     I usually deliberately write code to be be maintainable.  If it
is a bit slower, it usually does not matter (to me or mine).  However,
it could change, maybe years later, and I may have to change it
quickly.

     With the overoptimised one-liners, I usually have to unblock the
code to be able to implement the change.  A waste of time.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#9674

"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> on Sun, 24 Feb 2019
11:22:20 +0000 typed in alt.windows7.general  the following:
>
>Advice (and manuals, and sometimes even company procedures) often 
>recommend)s( a ratio of comment to code; whatever ratio is recommended, 
>of course, few of us follow that, and _usually_ without problem. It 
>_can_ be argued that well-written code is its own comment, and that can 
>_sometimes_ be the case - though efficient C does lend itself to 
>impenetrability. Also, the arguments about whether the compiler can 
>match the coder for efficiency will go on for ever, too. (Certainly I 
>used to think I could do better than any compiler, but that was decades 
>ago - though what I've seen recently of automatically-generated HTML has 
>certainly not impressed me.)

	There used to be code optimizers, but now I think were seeing the
use of more code pessimizers.
-- 
pyotr filipivich
Next month's Panel: Graft - Boon or blessing?

[toc] | [prev] | [next] | [standalone]

#9668

On 2019-02-24, Mr. Man-wai Chang <toylet.toylet@gmail.com> wrote:
> On 2/24/2019 12:11 PM, Mr. Man-wai Chang wrote:
>> On 2/24/2019 4:59 AM, jacobnavia wrote:
>>> http://delivery.acm.org/10.1145/3220000/3212479/p10-chisnall.pdf?ip=90.22.143.233&id=3212479&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&__acm__=1550954647_0d9af87c752b221627509ce89da282a8
>>> 
>> 
>> C is definitely no 4GL (4th generation language)!
>> But .... many 4GLs were written in C! :)
>> 
>
> And many operating systems are written in C.
> In short, C is a pillar!
>
dude you you have no fucking clue!
I'm not falling for your trolling bullshit,

-- 
  When I tried casting out nines I made a hash of it.

[toc] | [prev] | [next] | [standalone]

#9680

On 2/25/2019 4:43 AM, Jasen Betts wrote:
>
> dude you you have no fucking clue!
> I'm not falling for your trolling bullshit,

Generic, standard, multi-purpose answer to everything!

You really have the right to remain silent. Why did you respond? :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [next] | [standalone]

#9699

In message <q5013c$s9s$1@toylet.eternal-september.org>, Mr. Man-wai 
Chang <toylet.toylet@gmail.com> writes:
>On 2/25/2019 4:43 AM, Jasen Betts wrote:
>>
>> dude you you have no fucking clue!
>> I'm not falling for your trolling bullshit,
>
>Generic, standard, multi-purpose answer to everything!

I agree, but ...
>
>You really have the right to remain silent. Why did you respond? :)
>
... why did you (-:?
-- 
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

Science isn't about being right every time, or even most of the time. It is
about being more right over time and fixing what it got wrong.
- Scott Adams, 2015-2-2

[toc] | [prev] | [next] | [standalone]

#9700

On 2/25/2019 6:45 PM, J. P. Gilliver (John) wrote:
> 
> I agree, but ...
>>
>> ...
>>
> ... why did you (-:?

Let's get out of the loop! Deep sleep! :)

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
¤£­É¶U! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! 
½Ð¦Ò¼{ºî´© (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [standalone]

Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]

Back to top | Article view | comp.programming

csiph-web