Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #9626 > unrolled thread
| Started by | "Mr. Man-wai Chang" <toylet.toylet@gmail.com> |
|---|---|
| First post | 2019-02-24 12:40 +0800 |
| Last post | 2019-02-25 19:04 +0800 |
| Articles | 20 on this page of 180 — 32 participants |
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.
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 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | pyotr filipivich <phamp@mindspring.com> |
|---|---|
| Date | 2019-02-24 07:20 -0800 |
| Message-ID | <hvc57etmf4d2bpnguqeosjsetu3t3t48ov@4ax.com> |
| In reply to | #9643 |
"Mayayana" <mayayana@invalid.nospam> on Sun, 24 Feb 2019 08:51:59 -0500 typed in alt.windows7.general the following: >"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. And then there is obfuscated code. > -- pyotr filipivich Next month's Panel: Graft - Boon or blessing?
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> |
|---|---|
| Date | 2019-02-24 15:35 +0000 |
| Message-ID | <ty6LLtZumrccFwdb@255soft.uk> |
| In reply to | #9648 |
In message <hvc57etmf4d2bpnguqeosjsetu3t3t48ov@4ax.com>, pyotr filipivich <phamp@mindspring.com> writes: >"Mayayana" <mayayana@invalid.nospam> on Sun, 24 Feb 2019 08:51:59 >-0500 typed in alt.windows7.general the following: >>"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. That _can_ depend on the compiler; less-good ones may produce more steps for more readable code. > > And then there is obfuscated code. >> Deliberately so, you mean? I thought that was usually done by not giving access to the source code. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf You cannot simply assume someone is honest just because they are not an MP.
[toc] | [prev] | [next] | [standalone]
| From | "Mayayana" <mayayana@invalid.nospam> |
|---|---|
| Date | 2019-02-24 11:05 -0500 |
| Message-ID | <q4ufg6$ign$1@dont-email.me> |
| In reply to | #9649 |
"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> wrote | > And then there is obfuscated code. | > | Deliberately so, you mean? I thought that was usually done by not giving | access to the source code. I wondered about that, too. Though it is common these days for javascript to be obfuscated and deliberately complicated. Or it's pseudo-encrypted by doing things like including a string of byte values or Base64 in the script which is then reconstituted to the original. It also gets "minified", allegedly for compactness, but I think it's really for obfuscation. When you're pulling in 2 MB of javascript to do a simple task in a webpage, minifying is hardly relevant.
[toc] | [prev] | [next] | [standalone]
| From | pyotr filipivich <phamp@mindspring.com> |
|---|---|
| Date | 2019-02-24 14:39 -0800 |
| Message-ID | <0l667epbo7k9do14n1d38gfc5onn0imkgo@4ax.com> |
| In reply to | #9649 |
"J. P. Gilliver (John)" <G6JPG-255@255soft.uk> on Sun, 24 Feb 2019 15:35:10 +0000 typed in alt.windows7.general the following: >In message <hvc57etmf4d2bpnguqeosjsetu3t3t48ov@4ax.com>, pyotr >filipivich <phamp@mindspring.com> writes: >>"Mayayana" <mayayana@invalid.nospam> on Sun, 24 Feb 2019 08:51:59 >>-0500 typed in alt.windows7.general the following: >>>"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. > >That _can_ depend on the compiler; less-good ones may produce more steps >for more readable code. >> >> And then there is obfuscated code. >>> >Deliberately so, you mean? I thought that was usually done by not giving >access to the source code. There used to be an "Obfuscated Code" competition, where the idea was to write code so convoluted, that reading it was between really difficult and "Are you sure we're not going to summon one of the Elder gods doing this?" I recall one where the code listing looked like the letter Pi. But it compiled. Output was the value of Pi to some large number of places. I understand that back when memory was on a drum, legendary Programmers of Yore, would include the physical characteristic of the drum in their coding, so that rather than wait for the memory location to come round, it would read the memory location under the head, because the next instruction had been calculated to be there. But reading said code was very difficult unless you too were intimately familiar with the engineering of the memory system. There were Giants in those days. Also complete wackos. tschus pyotr -- APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums. -- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-02-24 19:11 -0800 |
| Message-ID | <ln4l8spnoy.fsf@kst-u.example.com> |
| In reply to | #9673 |
pyotr filipivich <phamp@mindspring.com> writes:
[...]
> There used to be an "Obfuscated Code" competition, where the idea
> was to write code so convoluted, that reading it was between really
> difficult and "Are you sure we're not going to summon one of the Elder
> gods doing this?"
There still is. https://ioccc.org/
> I recall one where the code listing looked like the
> letter Pi. But it compiled. Output was the value of Pi to some large
> number of places.
Here's the program, from the 1989 contest:
https://ioccc.org/1989/roemer.c
That's not quite what it does, but I don't want to spoil it.
(It seg faults when I compile it with gcc or clang, but it runs when I
compile it with tcc.)
[...]
(followups to comp.lang.c only.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Wolf K <wolfmac@sympatico.ca> |
|---|---|
| Date | 2019-02-25 09:41 -0500 |
| Message-ID | <j8TcE.148893$c46.43996@fx07.iad> |
| In reply to | #9673 |
On 2019-02-24 17:39, pyotr filipivich wrote: [snip the e tertainment] > There were Giants in those days. Also complete wackos. > > tschus > pyotr What I recall from my dabble in C/C+ many years ago was that it's a multi-level langauge. Very cool. But that means there was much opportunity for, er, let's call them "inadvertent" bugs. That's why there were giants and wackos. Their obsessively detailed knowledge of the language was necessary. Now that much (most?) programming done by bolting bits and pieces together, we get bloat, and, er, "inadvertent" security holes. Just sayin'. FTR, I took an IBM assembler about 40 years ago. Can still read maybe 20% of an assembler printout, but couldn't code my way out of paper bag. But by the end of the course, I could write 15-20 lines without a bug. The instructor said this was pretty good. -- Wolf K kirkwood40.blogspot.com A black cat crossing your path signifies that the animal is going somewhere. (Groucho Marx)
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> |
|---|---|
| Date | 2019-02-25 14:53 +0000 |
| Message-ID | <+BH$Xu6fFAdcFwF7@255soft.uk> |
| In reply to | #9709 |
In message <j8TcE.148893$c46.43996@fx07.iad>, Wolf K <wolfmac@sympatico.ca> writes: [] >FTR, I took an IBM assembler about 40 years ago. Can still read maybe >20% of an assembler printout, but couldn't code my way out of paper >bag. But by the end of the course, I could write 15-20 lines without a >bug. The instructor said this was pretty good. > 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. 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. Maybe nowadays assembler is _rare_? -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf You cannot simply assume someone is honest just because they are not an MP.
[toc] | [prev] | [next] | [standalone]
| From | Wolf K <wolfmac@sympatico.ca> |
|---|---|
| Date | 2019-02-25 10:19 -0500 |
| Message-ID | <6ITcE.119027$G52.102800@fx39.iad> |
| In reply to | #9710 |
On 2019-02-25 09:53, J. P. Gilliver (John) wrote: > In message <j8TcE.148893$c46.43996@fx07.iad>, Wolf K > <wolfmac@sympatico.ca> writes: > [] >> FTR, I took an IBM assembler about 40 years ago. Can still read maybe >> 20% of an assembler printout, but couldn't code my way out of paper >> bag. But by the end of the course, I could write 15-20 lines without a >> bug. The instructor said this was pretty good. >> > 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. > 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. > > Maybe nowadays assembler is _rare_? I think human-created assembler is becoming rare. However, I have the impression that robotics requires machine-coded assembler, translated from whatever human-readable language was used to program the machine. Those neat videos of dog=like robots loping through the building are misleading. Their abilities are not only severely limited, but those abilities were programmed on large machines cabled to the robot. The programs were tweaked and compressed before being copied to the on-board chips that control the "dog". Maybe someone from MIT or Boston Dynamics can clarify and correct. -- Wolf K kirkwood40.blogspot.com A black cat crossing your path signifies that the animal is going somewhere. (Groucho Marx)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-25 16:38 +0100 |
| Message-ID | <q51269$qdi$1@dont-email.me> |
| In reply to | #9712 |
On 25/02/2019 16:19, Wolf K wrote: > On 2019-02-25 09:53, J. P. Gilliver (John) wrote: >> In message <j8TcE.148893$c46.43996@fx07.iad>, Wolf K >> <wolfmac@sympatico.ca> writes: >> [] >>> FTR, I took an IBM assembler about 40 years ago. Can still read maybe >>> 20% of an assembler printout, but couldn't code my way out of paper >>> bag. But by the end of the course, I could write 15-20 lines without >>> a bug. The instructor said this was pretty good. >>> >> 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. >> 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. >> >> Maybe nowadays assembler is _rare_? > > I think human-created assembler is becoming rare. However, I have the > impression that robotics requires machine-coded assembler, translated > from whatever human-readable language was used to program the machine. > Those neat videos of dog=like robots loping through the building are > misleading. Their abilities are not only severely limited, but those > abilities were programmed on large machines cabled to the robot. The > programs were tweaked and compressed before being copied to the on-board > chips that control the "dog". There are almost no programming fields that require hand-written assembly these days. Even if you are writing a compiler, or low-level libraries for a compiler, you are unlikely to need more than small sections or snippets of assembly. There are still occasions where assembly will give you noticeably more efficient results than a high-level language - but very, very few where the difference is big enough to warrant using assembly. Generally, if you think assembly is the best choice then you have picked an inappropriate processor, inappropriate tools, or an inappropriate programmer. I think it is good for programmers to have some experience of assembly, and to have understanding of it - it helps give a better appreciation of how things work underneath, and can lead to the programmer writing better high-level code (especially on smaller systems). But that is different from actually writing assembly for real work. > > Maybe someone from MIT or Boston Dynamics can clarify and correct. >
[toc] | [prev] | [next] | [standalone]
| From | Wolf K <wolfmac@sympatico.ca> |
|---|---|
| Date | 2019-02-25 11:20 -0500 |
| Message-ID | <WAUcE.44777$NV.18824@fx42.iad> |
| In reply to | #9717 |
On 2019-02-25 10:38, David Brown wrote: [...] > There are almost no programming fields that require hand-written > assembly these days. Even if you are writing a compiler, or low-level > libraries for a compiler, you are unlikely to need more than small > sections or snippets of assembly. There are still occasions where > assembly will give you noticeably more efficient results than a > high-level language - but very, very few where the difference is big > enough to warrant using assembly. Generally, if you think assembly is > the best choice then you have picked an inappropriate processor, > inappropriate tools, or an inappropriate programmer. > > I think it is good for programmers to have some experience of assembly, > and to have understanding of it - it helps give a better appreciation of > how things work underneath, and can lead to the programmer writing > better high-level code (especially on smaller systems). But that is > different from actually writing assembly for real work. [...] Thanks for this, -- Wolf K kirkwood40.blogspot.com A black cat crossing your path signifies that the animal is going somewhere. (Groucho Marx)
[toc] | [prev] | [next] | [standalone]
| From | "J. P. Gilliver (John)" <G6JPG-255@255soft.uk> |
|---|---|
| Date | 2019-02-25 17:49 +0000 |
| Message-ID | <+tO$MQA5qCdcFwH+@255soft.uk> |
| In reply to | #9720 |
In message <WAUcE.44777$NV.18824@fx42.iad>, Wolf K <wolfmac@sympatico.ca> writes: >On 2019-02-25 10:38, David Brown wrote: >[...] >> There are almost no programming fields that require hand-written >> assembly these days. Even if you are writing a compiler, or low-level >> libraries for a compiler, you are unlikely to need more than small >> sections or snippets of assembly. There are still occasions where >> assembly will give you noticeably more efficient results than a >> high-level language - but very, very few where the difference is big >> enough to warrant using assembly. Generally, if you think assembly is >> the best choice then you have picked an inappropriate processor, >> inappropriate tools, or an inappropriate programmer. >> I think it is good for programmers to have some experience of >>assembly, >> and to have understanding of it - it helps give a better appreciation of >> how things work underneath, and can lead to the programmer writing >> better high-level code (especially on smaller systems). But that is >> different from actually writing assembly for real work. >[...] > >Thanks for this, > +1. I'd agree that - IMO anyway - it helps for programmers to have had some _experience_ of assembler, to - as you say - have a better appreciation of how things work underneath, and write better code. But there are now probably few places where the extra efficiency assembler can yield justifies the extra cost of _using_ it. (_Knowing_ about it I still think should be part of any training course that involves programming, though.) Yes, I still think assembler can produce more efficient code - but for all but the simplest systems, coding it requires more brain power (which costs money) than is justifiable in most cases: and _checking_ it is a really stressful activity: it requires phenomenal concentration. For any sizeable project, you need to have more than one coder working on it - and the effort they have to put into translating the inputs and outputs into a standard format to talk to each other arguably defeats the efficiency gains. If they _don't_ use standard interfaces, the _maintainability_ suffers, as any maintainer has to learn the details of the bespoke interfaces. This applies also for FPGA type work, too (programming in e. g. VHDL or High-C). _Ideally_, the compiler - or optimiser - will remove unnecessary format translation stages. The two places where ultimate efficiency matter are for very long-life, low-supply situations, such as space probes or similar situations, and _very_ mass-produced and cheap devices. And even for both of those, there are plenty of examples of where something went wrong - Ariane V, that hole in MoDem/router devices from a year or two ago - though I don't know in those particular cases whether it was in assembler or a medium-level or high-level language where the problem occurred. -- J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf The first objective of any tyrant in Whitehall would be to make Parliament utterly subservient to his will; and the next to overturn or diminish trial by jury ..." Lord Devlin (http://www.holbornchambers.co.uk)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-26 09:18 +0100 |
| Message-ID | <q52sou$u5l$1@dont-email.me> |
| In reply to | #9742 |
On 25/02/2019 18:49, J. P. Gilliver (John) wrote: > In message <WAUcE.44777$NV.18824@fx42.iad>, Wolf K > <wolfmac@sympatico.ca> writes: >> On 2019-02-25 10:38, David Brown wrote: >> [...] >>> There are almost no programming fields that require hand-written >>> assembly these days. Even if you are writing a compiler, or low-level >>> libraries for a compiler, you are unlikely to need more than small >>> sections or snippets of assembly. There are still occasions where >>> assembly will give you noticeably more efficient results than a >>> high-level language - but very, very few where the difference is big >>> enough to warrant using assembly. Generally, if you think assembly is >>> the best choice then you have picked an inappropriate processor, >>> inappropriate tools, or an inappropriate programmer. >>> I think it is good for programmers to have some experience of assembly, >>> and to have understanding of it - it helps give a better appreciation of >>> how things work underneath, and can lead to the programmer writing >>> better high-level code (especially on smaller systems). But that is >>> different from actually writing assembly for real work. >> [...] >> >> Thanks for this, >> > +1. I'd agree that - IMO anyway - it helps for programmers to have had > some _experience_ of assembler, to - as you say - have a better > appreciation of how things work underneath, and write better code. But > there are now probably few places where the extra efficiency assembler > can yield justifies the extra cost of _using_ it. (_Knowing_ about it I > still think should be part of any training course that involves > programming, though.) There are times when using some assembly code can help. It is almost always sufficient to use inline assembly mixed with high-level code (typically C or C++, possibly other compiled languages). You get the benefits of assembly mainly when the processor has features that are not easy to express in the main language - say, SIMD instructions. Combining inline assembly with high-level language (using a compiler that can support this well) is likely to give you more optimal code. > > Yes, I still think assembler can produce more efficient code - but for > all but the simplest systems, coding it requires more brain power (which > costs money) than is justifiable in most cases: and _checking_ it is a > really stressful activity: it requires phenomenal concentration. For any > sizeable project, you need to have more than one coder working on it - > and the effort they have to put into translating the inputs and outputs > into a standard format to talk to each other arguably defeats the > efficiency gains. If they _don't_ use standard interfaces, the > _maintainability_ suffers, as any maintainer has to learn the details of > the bespoke interfaces. > Yes. Obviously anything that /could/ be written in a high level language could also be written in assembly with at least as high efficiency on a particular target - and there are assembly tricks that can't be practically done with compilers. But while that is the theory, practice is very different. If you add some reasonable conditions - the code should be legible, maintainable, and portable within the ISA (e.g., it should work for any x86-64 cpu), then it is a very different matter. The high level code will almost always run faster than assembly written under these constraints. > This applies also for FPGA type work, too (programming in e. g. VHDL or > High-C). > Yes. > _Ideally_, the compiler - or optimiser - will remove unnecessary format > translation stages. > > The two places where ultimate efficiency matter are for very long-life, > low-supply situations, such as space probes or similar situations, and > _very_ mass-produced and cheap devices. And even for both of those, > there are plenty of examples of where something went wrong - Ariane V, > that hole in MoDem/router devices from a year or two ago - though I > don't know in those particular cases whether it was in assembler or a > medium-level or high-level language where the problem occurred.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 12:17 -0500 |
| Message-ID | <250220191217497304%nospam@nospam.invalid> |
| In reply to | #9717 |
In article <q51269$qdi$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: > There are almost no programming fields that require hand-written > assembly these days. Even if you are writing a compiler, or low-level > libraries for a compiler, you are unlikely to need more than small > sections or snippets of assembly. There are still occasions where > assembly will give you noticeably more efficient results than a > high-level language - but very, very few where the difference is big > enough to warrant using assembly. Generally, if you think assembly is > the best choice then you have picked an inappropriate processor, > inappropriate tools, or an inappropriate programmer. exactly > I think it is good for programmers to have some experience of assembly, > and to have understanding of it - it helps give a better appreciation of > how things work underneath, and can lead to the programmer writing > better high-level code (especially on smaller systems). But that is > different from actually writing assembly for real work. what matters the most are good algorithms, and knowing assembly does not help with that.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-25 20:25 +0200 |
| Message-ID | <0iodkf-v3o.ln1@gangtai.home.grep.be> |
| In reply to | #9728 |
On 25/02/2019 19:17, nospam wrote: > what matters the most are good algorithms, and knowing assembly does > not help with that. What helps with that is understanding of how a computer works; understanding the difference between registers and memory locations, and understanding how a processor performs calculations and stores the results of those calculations. It's impossible to write assembly language without at least a basic understanding of how computers work, and it's definitely the case that writing assembly language helps you learn that a bit more; so in that respect it most certainly does help with writing good algorithms.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-25 13:40 -0500 |
| Message-ID | <250220191340486069%nospam@nospam.invalid> |
| In reply to | #9732 |
In article <0iodkf-v3o.ln1@gangtai.home.grep.be>, Wouter Verhelst <w@uter.be> wrote: > > what matters the most are good algorithms, and knowing assembly does > > not help with that. > > What helps with that is understanding of how a computer works; > understanding the difference between registers and memory locations, and > understanding how a processor performs calculations and stores the > results of those calculations. that does not matter. what matters is using the best algorithm for a given task. a shitty algorithm written in highly optimized assembly and using only registers is still a shitty algorithm. > It's impossible to write assembly language without at least a basic > understanding of how computers work, and it's definitely the case that > writing assembly language helps you learn that a bit more; so in that > respect it most certainly does help with writing good algorithms. with *very* rare exception, there's no longer a need to write assembly language anymore.
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2019-02-26 12:45 +0200 |
| Message-ID | <7vhfkf-64b.ln1@gangtai.home.grep.be> |
| In reply to | #9747 |
On 25/02/2019 20:40, nospam wrote: > In article <0iodkf-v3o.ln1@gangtai.home.grep.be>, Wouter Verhelst > <w@uter.be> wrote: > >>> what matters the most are good algorithms, and knowing assembly does >>> not help with that. >> >> What helps with that is understanding of how a computer works; >> understanding the difference between registers and memory locations, and >> understanding how a processor performs calculations and stores the >> results of those calculations. > > that does not matter. Yes it does. > what matters is using the best algorithm for a given task. The best algorithm to break RSA requires a quantum computer. It's a very good algorithm, but on a standard computer it will not perform very well. The same is true for very many other algorithms: they may be very good, but will not perform well on real hardware. If you need to design an algorithm, it helps if you understand how the hardware works. > a shitty algorithm written in highly optimized assembly and using only > registers is still a shitty algorithm. I didn't say that. I said it helps to design good algorithms if you understand how the hardware works. Once you do, it does not matter whether you write that algorithm in C, Pascal, or Assembler. >> It's impossible to write assembly language without at least a basic >> understanding of how computers work, and it's definitely the case that >> writing assembly language helps you learn that a bit more; so in that >> respect it most certainly does help with writing good algorithms. > > with *very* rare exception, there's no longer a need to write assembly > language anymore. That's pretty extremely far besides the point I was trying to make...
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2019-02-26 08:02 -0500 |
| Message-ID | <260220190802243732%nospam@nospam.invalid> |
| In reply to | #9775 |
In article <7vhfkf-64b.ln1@gangtai.home.grep.be>, Wouter Verhelst <w@uter.be> wrote: > >>> what matters the most are good algorithms, and knowing assembly does > >>> not help with that. > >> > >> What helps with that is understanding of how a computer works; > >> understanding the difference between registers and memory locations, and > >> understanding how a processor performs calculations and stores the > >> results of those calculations. > > > > that does not matter. > > Yes it does. no, it does not. > > what matters is using the best algorithm for a given task. > > The best algorithm to break RSA requires a quantum computer. > > It's a very good algorithm, but on a standard computer it will not > perform very well. that's entirely different. > The same is true for very many other algorithms: they may be very good, > but will not perform well on real hardware. nonsense. > If you need to design an algorithm, it helps if you understand how the > hardware works. nope. the hardware is irrelevant. a good algorithm will still be good if the hardware changes. a shitty algorithm makes assumptions about the hardware, and when it does change, does not work well, or at all. > > a shitty algorithm written in highly optimized assembly and using only > > registers is still a shitty algorithm. > > I didn't say that. I said it helps to design good algorithms if you > understand how the hardware works. Once you do, it does not matter > whether you write that algorithm in C, Pascal, or Assembler. it makes little difference how the hardware works. > >> It's impossible to write assembly language without at least a basic > >> understanding of how computers work, and it's definitely the case that > >> writing assembly language helps you learn that a bit more; so in that > >> respect it most certainly does help with writing good algorithms. > > > > with *very* rare exception, there's no longer a need to write assembly > > language anymore. > > That's pretty extremely far besides the point I was trying to make... it's correct. modern compilers generate code far better than any human can do in almost every case.
[toc] | [prev] | [next] | [standalone]
| From | Wolf K <wolfmac@sympatico.ca> |
|---|---|
| Date | 2019-02-26 09:11 -0500 |
| Message-ID | <_NbdE.11772$Yo2.9213@fx31.iad> |
| In reply to | #9775 |
On 2019-02-26 05:45, Wouter Verhelst wrote: > On 25/02/2019 20:40, nospam wrote: >> In article <0iodkf-v3o.ln1@gangtai.home.grep.be>, Wouter Verhelst >> <w@uter.be> wrote: >> >>>> what matters the most are good algorithms, and knowing assembly does >>>> not help with that. >>> >>> What helps with that is understanding of how a computer works; >>> understanding the difference between registers and memory locations, and >>> understanding how a processor performs calculations and stores the >>> results of those calculations. >> >> that does not matter. > > Yes it does. > >> what matters is using the best algorithm for a given task. > > The best algorithm to break RSA requires a quantum computer. > > It's a very good algorithm, but on a standard computer it will not > perform very well. > > The same is true for very many other algorithms: they may be very good, > but will not perform well on real hardware. > > If you need to design an algorithm, it helps if you understand how the > hardware works. > >> a shitty algorithm written in highly optimized assembly and using only >> registers is still a shitty algorithm. > > I didn't say that. I said it helps to design good algorithms if you > understand how the hardware works. Once you do, it does not matter > whether you write that algorithm in C, Pascal, or Assembler. > >>> It's impossible to write assembly language without at least a basic >>> understanding of how computers work, and it's definitely the case that >>> writing assembly language helps you learn that a bit more; so in that >>> respect it most certainly does help with writing good algorithms. >> >> with *very* rare exception, there's no longer a need to write assembly >> language anymore. > > That's pretty extremely far besides the point I was trying to make... > Ancient wisdom: "Do not let the the desire for perfection prevent the acceptance of the good." -- Wolf K kirkwood40.blogspot.com A black cat crossing your path signifies that the animal is going somewhere. (Groucho Marx)
[toc] | [prev] | [next] | [standalone]
| From | Diesel <nobody@haph.org> |
|---|---|
| Date | 2019-03-05 04:29 +0000 |
| Message-ID | <XnsAA08EFC8411C5HT1@doCX0.74.zmu4y91> |
| In reply to | #9732 |
Wouter Verhelst <w@uter.be> news:0iodkf-v3o.ln1@gangtai.home.grep.be Mon, 25 Feb 2019 18:25:35 GMT in alt.windows7.general, wrote: > On 25/02/2019 19:17, nospam wrote: >> what matters the most are good algorithms, and knowing assembly >> does not help with that. > > What helps with that is understanding of how a computer works; > understanding the difference between registers and memory > locations, and understanding how a processor performs calculations > and stores the results of those calculations. > > It's impossible to write assembly language without at least a > basic understanding of how computers work, and it's definitely the > case that writing assembly language helps you learn that a bit > more; so in that respect it most certainly does help with writing > good algorithms. Agreed! -- Friends help you move. Real friends help you move bodies.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-02-26 09:23 +0100 |
| Message-ID | <q52t2e$vqb$1@dont-email.me> |
| In reply to | #9728 |
On 25/02/2019 18:17, nospam wrote: > In article <q51269$qdi$1@dont-email.me>, David Brown > <david.brown@hesbynett.no> wrote: > >> There are almost no programming fields that require hand-written >> assembly these days. Even if you are writing a compiler, or low-level >> libraries for a compiler, you are unlikely to need more than small >> sections or snippets of assembly. There are still occasions where >> assembly will give you noticeably more efficient results than a >> high-level language - but very, very few where the difference is big >> enough to warrant using assembly. Generally, if you think assembly is >> the best choice then you have picked an inappropriate processor, >> inappropriate tools, or an inappropriate programmer. > > exactly > >> I think it is good for programmers to have some experience of assembly, >> and to have understanding of it - it helps give a better appreciation of >> how things work underneath, and can lead to the programmer writing >> better high-level code (especially on smaller systems). But that is >> different from actually writing assembly for real work. > > what matters the most are good algorithms, and knowing assembly does > not help with that. > That is often the case - but certainly not always. Good algorithms are important when "n" is big - but "n" is usually small. For a small enough size, bubblesort will beat heapsort. Good algorithms are not to be underestimated - but not overestimated either. And knowing assembly can give better algorithm implementations, simply because the programmer is more aware of the underlying hardware. It can help when you are trying to decide if you should be fiddling with objects, or pointers to objects, for example.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.programming
csiph-web