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

Groups > comp.lang.c > #76081 > unrolled thread

Array manipulation techniques

Back to article view | Back to comp.lang.c

Contents

  Array manipulation techniques "Morten W. Petersen" <morphex@gmail.com> - 2015-11-15 09:44 +0100
    Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 01:56 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 10:43 -0800
        Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 10:54 -0800
          Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-16 08:13 +1300
            Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:50 -0800
          Re: Array manipulation techniques Les Cargill <lcargill99@comcast.com> - 2015-11-15 14:07 -0600
        Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 15:12 -0800
    Re: Array manipulation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-15 09:57 +0000
    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-15 03:02 -0800
    Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:02 -0800
      Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:05 -0800
        Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:28 -0800
          Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:48 -0800
          Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:05 -0800
            Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 19:09 -0800
            Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 22:52 -0800
              Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:00 -0800
                Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:17 +0000
                  Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:41 -0800
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:47 +0000
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-16 09:51 +0100
                        Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:49 +0000
                  Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-16 11:10 +0000
                    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 03:33 -0800
                      Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 13:09 +0000
                        Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 05:59 -0800
                          Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 15:22 +0000
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:57 +0000
                    Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:29 -0800
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 09:02 +0100
                        Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 10:46 +0000
                        Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-17 07:05 -0800
                          Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 16:47 +0100
                            Re: Array manipulation techniques supercat@casperkitty.com - 2015-11-17 12:33 -0800
                Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 12:15 -0500
                  Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 10:33 -0800
                    Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 10:51 -0800
                      Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-16 20:14 +0100
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 11:28 -0800
                          Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-17 00:20 +0100
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 10:03 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-17 08:54 -0800
                            Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 20:12 +0000
                              Re: Development Best Practices and C "nomenclature" Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:38 -0600
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:22 +0000
                      Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:25 +0000
                      Re: Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 16:20 -0500
                        Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 13:28 -0800
                        Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 21:30 +0000
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:38 -0800
                          Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:52 -0800
                            Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-17 22:51 -0800
                              Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 06:59 +0000
                    Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:24 +0000
                    Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 09:55 +0100
                      Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 23:00 +0000
                  Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:55 +0000
                    Re: Development Best Practices and C "nomenclature" Ian Collins <ian-news@hotmail.com> - 2015-11-18 12:07 +1300
                      Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-17 18:45 -0500
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-18 15:50 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 08:39 -0800
                            Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:07 -0800
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-20 14:16 -0800
                                [OT] Re: Development Best Practices and C "nomenclature" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 17:30 -0500
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 19:29 -0800
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-21 22:44 +0000
                            Re: Development Best Practices and C "nomenclature" jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-22 00:09 +0100
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-21 15:57 -0800
                                Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-21 20:49 -0500
                                  Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-25 10:13 +0100
                                    Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-25 18:58 -0500
                                      Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-26 12:13 +0100
                                        Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-26 07:22 -0500
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:51 +0000
                                  Re: Development Best Practices and C "nomenclature" "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-23 15:53 -0600
                          Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 08:55 -0800
                            Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 09:17 -0800
                          Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:19 -0500
                          Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:32 +0000
                  Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:17 -0800
                    Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 07:08 +0000
                      Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 13:52 -0800
        Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:03 -0800
      Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-15 15:09 -0500
      Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-15 21:47 +0000
      Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:02 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:44 -0800
        Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-16 11:13 -0800
          Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 11:57 -0800
            Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-17 10:30 +1300
          Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-17 08:11 -0500
            Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 13:24 +0000
            Re: Array manipulation techniques Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:09 -0800
              Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 16:20 -0500

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#76405 — Re: Development Best Practices and C "nomenclature"

On 18/11/15 00:45, James Kuyper wrote:
> On 11/17/2015 06:07 PM, Ian Collins wrote:
>> Richard Bos wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
>>>
>>>> On Monday November 16 2015 02:00, in comp.lang.c, "asetofsymbols@gmail.com"
>>>>
>>>>> This seems right:
>>>>> #define u8 unsigned char
>>>>> #define i32 int
>>>>> #define u32 unsigned int
>>>>>
>>>>> #define R return
>>>>> #define F for
>>>>
>>>> These are the sorts of things I would expect to see in "personal" code (code
>>>> not intended for anyone's eyes other than the author).
>>>
>>> Would you? I wouldn't expect them even there. The only place they ought
>>> to be found is the IOCCC. Or a Perl program.
>>
>> I thought all Perl programs were potential IOCCC entries...
> 
> I often wondered where this stereotype comes from. Most of the perl
> scripts I've seen are no worse than typical C or C++ programs in this
> regard. I'm sure it's possible to obfuscate perl code at least as badly
> as you can obfuscate C code, but serious professionals don't do that,
> and there's nothing about perl that forces or even encourages you to
> write such code.
> 

The reputation comes from perl scripts that are hacked together to do a
single job.  Often this involves a horrendous regular expression or two.
 The script makes sense at the time, with trial-and-error debugging of
the regular expressions and the developer's notes on a scrap of paper.
The problem comes when this throw-away script is re-used as part of a
bigger program or a permanent feature in a system.

More serious perl code and larger programs will be as well-designed or
badly-designed as for any other language.

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

#76415 — Re: Development Best Practices and C "nomenclature"

David Brown <david.brown@hesbynett.no> writes:
[...]
> The reputation comes from perl scripts that are hacked together to do a
> single job.  Often this involves a horrendous regular expression or two.
>  The script makes sense at the time, with trial-and-error debugging of
> the regular expressions and the developer's notes on a scrap of paper.
> The problem comes when this throw-away script is re-used as part of a
> bigger program or a permanent feature in a system.
>
> More serious perl code and larger programs will be as well-designed or
> badly-designed as for any other language.

Just as you can write Fortran in any language, you can write APL in any
language.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76673 — Re: Development Best Practices and C "nomenclature"

Keith Thompson <kst-u@mib.org> writes:

> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The reputation comes from perl scripts that are hacked together to do a
>> single job.  Often this involves a horrendous regular expression or two.
>>  The script makes sense at the time, with trial-and-error debugging of
>> the regular expressions and the developer's notes on a scrap of paper.
>> The problem comes when this throw-away script is re-used as part of a
>> bigger program or a permanent feature in a system.
>>
>> More serious perl code and larger programs will be as well-designed or
>> badly-designed as for any other language.
>
> Just as you can write Fortran in any language, you can write APL in any
> language.

Oh I think I have to take issue with that last part.  In most
typical procedural/imperative languages there really isn't a way
to write code the way it would be written in APL.  Some of it can
be sort of faked by using functions and an elaborate dynamic type
system, but that doesn't scale up enough to be usable for
full-sized programs.

If you're talking about APL's reputation for being impenetrable
and a "write-only" language, of course that's another story.

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

#76687 — Re: Development Best Practices and C "nomenclature"

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> The reputation comes from perl scripts that are hacked together to do a
>>> single job.  Often this involves a horrendous regular expression or two.
>>>  The script makes sense at the time, with trial-and-error debugging of
>>> the regular expressions and the developer's notes on a scrap of paper.
>>> The problem comes when this throw-away script is re-used as part of a
>>> bigger program or a permanent feature in a system.
>>>
>>> More serious perl code and larger programs will be as well-designed or
>>> badly-designed as for any other language.
>>
>> Just as you can write Fortran in any language, you can write APL in any
>> language.
>
> Oh I think I have to take issue with that last part.  In most
> typical procedural/imperative languages there really isn't a way
> to write code the way it would be written in APL.  Some of it can
> be sort of faked by using functions and an elaborate dynamic type
> system, but that doesn't scale up enough to be usable for
> full-sized programs.
>
> If you're talking about APL's reputation for being impenetrable
> and a "write-only" language, of course that's another story.

Yes, that's what I meant.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76688 — [OT] Re: Development Best Practices and C "nomenclature"

On 11/20/2015 5:16 PM, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>[...]
>> If you're talking about APL's reputation for being impenetrable
>> and a "write-only" language, of course that's another story.
>
> Yes, that's what I meant.

     I recall reading a fantasy story about the downfall of an
evil sorcerer.  The interesting gimmick was that magic spells
are so complex that even the most masterful of mages could not
possibly memorize more than a few; our anti-hero could cope (I
think) with five.  Also, using a spell had an interesting side-
effect: Having used it, the magician immediately forgot it and
could not use it again until he'd consulted his grimoires and
gone to the mind-bending effort of re-memorizing it.

     Dunno whether the author used APL, but it seems plausible ...

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

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

#76714 — Re: [OT] Re: Development Best Practices and C "nomenclature"

On Friday, November 20, 2015 at 10:30:22 PM UTC, Eric Sosman wrote:
> On 11/20/2015 5:16 PM, Keith Thompson wrote:
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>[...]
> >> If you're talking about APL's reputation for being impenetrable
> >> and a "write-only" language, of course that's another story.
> >
> > Yes, that's what I meant.
> 
>      I recall reading a fantasy story about the downfall of an
> evil sorcerer.  The interesting gimmick was that magic spells
> are so complex that even the most masterful of mages could not
> possibly memorize more than a few; our anti-hero could cope (I
> think) with five.  Also, using a spell had an interesting side-
> effect: Having used it, the magician immediately forgot it and
> could not use it again until he'd consulted his grimoires and
> gone to the mind-bending effort of re-memorizing it.
> 
>      Dunno whether the author used APL, but it seems plausible ...
> 
Those are standard Dungeons and Dragons rules.
(Awful revelation here)

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

#76808 — Re: [OT] Re: Development Best Practices and C "nomenclature"

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:

> On 11/20/2015 5:16 PM, Keith Thompson wrote:
> > Tim Rentsch <txr@alumni.caltech.edu> writes:
> >>[...]
> >> If you're talking about APL's reputation for being impenetrable
> >> and a "write-only" language, of course that's another story.
> >
> > Yes, that's what I meant.
> 
>      I recall reading a fantasy story about the downfall of an
> evil sorcerer.  The interesting gimmick was that magic spells
> are so complex that even the most masterful of mages could not
> possibly memorize more than a few; our anti-hero could cope (I
> think) with five.  Also, using a spell had an interesting side-
> effect: Having used it, the magician immediately forgot it and
> could not use it again until he'd consulted his grimoires and
> gone to the mind-bending effort of re-memorizing it.

Either Jack Vance (Dying Earth?), an imitator, or a D&D or Infocom
novelisation. Or an Infocom game, which based their system of magic,
possibly indirectly via D&D, on Vance's.

Richard

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

#76809 — Re: Development Best Practices and C "nomenclature"

Le 18/11/2015 17:39, Keith Thompson a écrit :

> Just as you can write Fortran in any language, you can write APL in any
> language.
>

Yes, I have been doing it for decades. APL brought array processing into 
view. In APL everything is an array (like in Lisp lists)

It doesn't use any human language to communicate orders to the machine 
but a symbolic language with a very simple syntax and precedence rules 
using greek symbols. (iota, nabla, and other composed symbols like +/ 
for reduction.

APL was an incredible innovative language at the end of the seventies. 
An incorporated debugger, and a concise syntax allowed you to create big 
systems with very few keystrokes and effort. We had in 1980 at STSC an 
"Excel" like system but MUCH more sophisticated than what Excel will 
ever be. "Quickcalc" was called.

We had databases using EMMA (Extended Macro Management in APL), using 
the APL file system.

In APL a file system was just a series of sequential "components", that 
could contain  anything. Complex APL objects and hierarchies could be 
stored with simple commands.

We had a special APL keyboard that allowed us to write our programs, and 
special typewriter "heads" that could print them.

Yes, ignorants will scorn at APL for his famous "look": a series of 
greek symbols that look absolutely horrifying for the uninitiated.

So what?

They never understood APL. Nor do they understand it today, when they 
write nonsense like

"... you can write APL in any language".

No, Thompson, you can't.

jacob

Bibliography
[1]
A Programming language
K. Iverson. See here for a pdf of the original 1962 version.
http://www.softwarepreservation.org/projects/apl/Books/APROGRAMMING%20LANGUAGE

[2] Notation as a tool of thought
K. Iversion 1979 Turin Award Lecture
http://www.jdl.ac.cn/turing/pdf/p444-iverson.pdf

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

#76812 — Re: Development Best Practices and C "nomenclature"

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 18/11/2015 17:39, Keith Thompson a écrit :
>> Just as you can write Fortran in any language, you can write APL in any
>> language.
>
> Yes, I have been doing it for decades. APL brought array processing into 
> view. In APL everything is an array (like in Lisp lists)
[...]
> Yes, ignorants will scorn at APL for his famous "look": a series of 
> greek symbols that look absolutely horrifying for the uninitiated.
>
> So what?
>
> They never understood APL. Nor do they understand it today, when they 
> write nonsense like
>
> "... you can write APL in any language".
>
> No, Thompson, you can't.
[...]

I admit I'm not very familiar with APL.  It has a reputation as a
"write-only" language.  I've heard stories of 4-line APL programs
written by experts who couldn't read their own code a day later.
My understanding, though, is that it's a good and powerful language
for the niche for which it was designed.

I actually didn't intend to criticize APL itself.  Rather my
criticism was directed at, for example, C programmers who write
excessively terse code.  "APL in any language" is not a completely
accurate description, more of a stand-in for misusing one language's
style in another, like writing BASIC-style C with line numbers
and gotos.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76822 — Re: Development Best Practices and C "nomenclature"

On 11/21/2015 06:57 PM, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 18/11/2015 17:39, Keith Thompson a écrit :
>>> Just as you can write Fortran in any language, you can write APL in any
>>> language.
>>
>> Yes, I have been doing it for decades. APL brought array processing into 
>> view. In APL everything is an array (like in Lisp lists)
> [...]
>> Yes, ignorants will scorn at APL for his famous "look": a series of 
>> greek symbols that look absolutely horrifying for the uninitiated.
>>
>> So what?
>>
>> They never understood APL. Nor do they understand it today, when they 
>> write nonsense like
>>
>> "... you can write APL in any language".
>>
>> No, Thompson, you can't.
> [...]
> 
> I admit I'm not very familiar with APL.  It has a reputation as a
> "write-only" language.  I've heard stories of 4-line APL programs
> written by experts who couldn't read their own code a day later.

I wrote several hundred lines of APL code in 1976, didn't make any
significant use of APL for the next 20 years, and then found an old
printout of my code when I was preparing for a move. I had no trouble
reading it and understanding precisely what it did, and how. I couldn't
write such a program again without spending a good deal of time brushing
up on the language, but it was quite readable.

> My understanding, though, is that it's a good and powerful language
> for the niche for which it was designed.
> 
> I actually didn't intend to criticize APL itself.  Rather my
> criticism was directed at, for example, C programmers who write
> excessively terse code.  "APL in any language" is not a completely
> accurate description, more of a stand-in for misusing one language's
> style in another, like writing BASIC-style C with line numbers
> and gotos.

And the thing wrong with that statement is that APL's style is so unique
that it's virtually impossible to use that style in any other language,
so misusing it in another language just isn't an option.
-- 
James Kuyper

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

#77154 — Re: Development Best Practices and C "nomenclature"

[comp.lang.apl, comp.lang.c]
On Sat, 21 Nov 2015 20:49:41 -0500, James Kuyper wrote:
>On 11/21/2015 06:57 PM, Keith Thompson wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 18/11/2015 17:39, Keith Thompson a écrit :
>>>> Just as you can write Fortran in any language, you can write APL in any
>>>> language.
>>>
>>> Yes, I have been doing it for decades. APL brought array processing into 
>>> view. In APL everything is an array (like in Lisp lists)
>> [...]
>>> Yes, ignorants will scorn at APL for his famous "look": a series of 
>>> greek symbols that look absolutely horrifying for the uninitiated.
>>>
>>> So what?
>>>
>>> They never understood APL. Nor do they understand it today, when they 
>>> write nonsense like
>>>
>>> "... you can write APL in any language".
>>>
>>> No, Thompson, you can't.
>> [...]
>> 
>> I admit I'm not very familiar with APL.  It has a reputation as a
>> "write-only" language.  I've heard stories of 4-line APL programs
>> written by experts who couldn't read their own code a day later.
>
>I wrote several hundred lines of APL code in 1976, didn't make any
>significant use of APL for the next 20 years, and then found an old
>printout of my code when I was preparing for a move. I had no trouble
>reading it and understanding precisely what it did, and how. I couldn't
>write such a program again without spending a good deal of time brushing
>up on the language, but it was quite readable.
>
>> My understanding, though, is that it's a good and powerful language
>> for the niche for which it was designed.
>> 
>> I actually didn't intend to criticize APL itself.  Rather my
>> criticism was directed at, for example, C programmers who write
>> excessively terse code.  "APL in any language" is not a completely
>> accurate description, more of a stand-in for misusing one language's
>> style in another, like writing BASIC-style C with line numbers
>> and gotos.
>
>And the thing wrong with that statement is that APL's style is so unique
>that it's virtually impossible to use that style in any other language,
>so misusing it in another language just isn't an option.

i have no experience in apl, but at first see could say
the problem of that language is the same of all other hll languages
so C and C++ too

1) identify the riht primitive:few operators, functions, 
   loops keyword type, 
   one can build easily all the remain of algorithms
          (and in this C is very good)
   and they would not occupy too much space in the
   screen (and in this apl is good)
   so each primitive instruction has to be few simbols
   as F() for for(), or G for goto
for example i think some important types would be
   big int,
   big float fixed point with choosable precision
   8bit unsigned for array of chars
   could be useful u8, i8 u16 u32 etc
   int and unsigned fixed types
   types build on them as struct in C
   and matrices use types above 
   
for the loops would be useful 
the if()           as in C
the F(;;) for loop as in C
the goto label primitive  G(condition, label)

2) use or allow to use the return result of function
   for see if the function computation is ok
   (and not use 95% time exceptions)
   or better
   all the type has at last one bit in them
   descrive if they contain valid value and are right 
   and free of errors. 
   so the error object
   one object has in it one not valid value: is one error obj
   one object result of one function with some argument 
   error obj as argument: it is the error object

So if i print a error object it would print "Error Object"
 so seen that i see there is some problem,
and sys in every moment can check if one object is
right or wrong

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

#77193 — Re: Development Best Practices and C "nomenclature"

In article <ipua5b9ur7e933a7benqgc6aj8deiipdc7@4ax.com>, 
Ros@invalid.invalid says...
> 
> [comp.lang.apl, comp.lang.c]
> On Sat, 21 Nov 2015 20:49:41 -0500, James Kuyper wrote:
> >On 11/21/2015 06:57 PM, Keith Thompson wrote:
> >> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >>> Le 18/11/2015 17:39, Keith Thompson a écrit :
> >>>> Just as you can write Fortran in any language, you can write APL in any
> >>>> language.
> >>>
> >>> Yes, I have been doing it for decades. APL brought array processing into 
> >>> view. In APL everything is an array (like in Lisp lists)
> >> [...]
> >>> Yes, ignorants will scorn at APL for his famous "look": a series of 
> >>> greek symbols that look absolutely horrifying for the uninitiated.
> >>>
> >>> So what?
> >>>
> >>> They never understood APL. Nor do they understand it today, when they 
> >>> write nonsense like
> >>>
> >>> "... you can write APL in any language".
> >>>
> >>> No, Thompson, you can't.
> >> [...]
> >> 
> >> I admit I'm not very familiar with APL.  It has a reputation as a
> >> "write-only" language.  I've heard stories of 4-line APL programs
> >> written by experts who couldn't read their own code a day later.
> >
> >I wrote several hundred lines of APL code in 1976, didn't make any
> >significant use of APL for the next 20 years, and then found an old
> >printout of my code when I was preparing for a move. I had no trouble
> >reading it and understanding precisely what it did, and how. I couldn't
> >write such a program again without spending a good deal of time brushing
> >up on the language, but it was quite readable.
> >
> >> My understanding, though, is that it's a good and powerful language
> >> for the niche for which it was designed.
> >> 
> >> I actually didn't intend to criticize APL itself.  Rather my
> >> criticism was directed at, for example, C programmers who write
> >> excessively terse code.  "APL in any language" is not a completely
> >> accurate description, more of a stand-in for misusing one language's
> >> style in another, like writing BASIC-style C with line numbers
> >> and gotos.
> >
> >And the thing wrong with that statement is that APL's style is so unique
> >that it's virtually impossible to use that style in any other language,
> >so misusing it in another language just isn't an option.
> 
> i have no experience in apl, but at first see could say
> the problem of that language is the same of all other hll languages
> so C and C++ too
> 
> 1) identify the riht primitive:few operators, functions, 
>    loops keyword type, 
>    one can build easily all the remain of algorithms
>           (and in this C is very good)
>    and they would not occupy too much space in the
>    screen (and in this apl is good)
>    so each primitive instruction has to be few simbols
>    as F() for for(), or G for goto

There are on the order of a hundred operators, most of which give 
different behaviors when used monadically or dyadically, and different 
behaviors when used with a scalar, vector, array, or operator argumnent.  
Some of them do rather complicated things, especially when used with 
operator arguments.
 
> for example i think some important types would be
>    big int,
>    big float fixed point with choosable precision
>    8bit unsigned for array of chars
>    could be useful u8, i8 u16 u32 etc
>    int and unsigned fixed types
>    types build on them as struct in C
>    and matrices use types above 

APL types are scalar, vector, array, and character.  There's no "big 
int" or "big float" or the like--APL doesn't make that distinction.  
There are versions that let you set a flag to use native operations or 
arbitrary-precision but that's about it.
    
> for the loops would be useful 
> the if()           as in C
> the F(;;) for loop as in C
> the goto label primitive  G(condition, label)

In general if you are looping in APL it should be setting off red 
flags--its usually a sign that you're "writing Fortran".
> 
> 2) use or allow to use the return result of function
>    for see if the function computation is ok
>    (and not use 95% time exceptions)
>    or better
>    all the type has at last one bit in them
>    descrive if they contain valid value and are right 
>    and free of errors. 
>    so the error object
>    one object has in it one not valid value: is one error obj
>    one object result of one function with some argument 
>    error obj as argument: it is the error object

Objects are another recent addition to APL.
 
> So if i print a error object it would print "Error Object"
>  so seen that i see there is some problem,
> and sys in every moment can check if one object is
> right or wrong

I see you're on Windows--download NARS2000 and try porting some of your 
C code to APL, with the proviso that you always ask "how can I do this 
without a loop".  You'll find that your APL code ends up looking not at 
all like your C code and is usually _very_ compact.

The reputation as a "write only language" comes from the tendency of APL 
programmers at a certain stage of their development trying to write 
everything as one liners--take an inch thick listing in C and write it 
in one line of APL.  The information density there is so high as to 
sometimes be impenetrable.

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

#77210 — Re: Development Best Practices and C "nomenclature"

On Wed, 25 Nov 2015 18:58:53 -0500, "J. Clarke" wrote:
>In article <ipua5b9ur7e933a7benqgc6aj8deiipdc7@4ax.com>, 
>Ros@invalid.invalid says... 
>> [comp.lang.apl, comp.lang.c]
>> On Sat, 21 Nov 2015 20:49:41 -0500, James Kuyper wrote:
>> >On 11/21/2015 06:57 PM, Keith Thompson wrote:
>> >> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> >>> Le 18/11/2015 17:39, Keith Thompson a écrit :
>> >>>> Just as you can write Fortran in any language, you can write APL in any
>> >>>> language.
>> >>>
>> >>> Yes, I have been doing it for decades. APL brought array processing into 
>> >>> view. In APL everything is an array (like in Lisp lists)
>> >> [...]
>> >>> Yes, ignorants will scorn at APL for his famous "look": a series of 
>> >>> greek symbols that look absolutely horrifying for the uninitiated.
>> >>>
>> >>> So what?
>> >>>
>> >>> They never understood APL. Nor do they understand it today, when they 
>> >>> write nonsense like
>> >>>
>> >>> "... you can write APL in any language".
>> >>>
>> >>> No, Thompson, you can't.
>> >> [...]
>> >> 
>> >> I admit I'm not very familiar with APL.  It has a reputation as a
>> >> "write-only" language.  I've heard stories of 4-line APL programs
>> >> written by experts who couldn't read their own code a day later.
>> >
>> >I wrote several hundred lines of APL code in 1976, didn't make any
>> >significant use of APL for the next 20 years, and then found an old
>> >printout of my code when I was preparing for a move. I had no trouble
>> >reading it and understanding precisely what it did, and how. I couldn't
>> >write such a program again without spending a good deal of time brushing
>> >up on the language, but it was quite readable.
>> >
>> >> My understanding, though, is that it's a good and powerful language
>> >> for the niche for which it was designed.
>> >> 
>> >> I actually didn't intend to criticize APL itself.  Rather my
>> >> criticism was directed at, for example, C programmers who write
>> >> excessively terse code.  "APL in any language" is not a completely
>> >> accurate description, more of a stand-in for misusing one language's
>> >> style in another, like writing BASIC-style C with line numbers
>> >> and gotos.
>> >
>> >And the thing wrong with that statement is that APL's style is so unique
>> >that it's virtually impossible to use that style in any other language,
>> >so misusing it in another language just isn't an option.
>> 
>> i have no experience in apl, but at first see could say
>> the problem of that language is the same of all other hll languages
>> so C and C++ too
>> 
>> 1) identify the riht primitive:few operators, functions, 
>>    loops keyword type, 
>>    one can build easily all the remain of algorithms
>>           (and in this C is very good)
>>    and they would not occupy too much space in the
>>    screen (and in this apl is good)
>>    so each primitive instruction has to be few simbols
>>    as F() for for(), or G for goto
>
>There are on the order of a hundred operators, most of which give

"hundred" operators could be too much...
operators could be few on matrix... and these would be ok for vectors
and scalar too... a litle long sentence but one understand better
 
>different behaviors when used monadically or dyadically, and different 
>behaviors when used with a scalar, vector, array, or operator argumnent.  
>Some of them do rather complicated things, especially when used with 
>operator arguments.
> 
>> for example i think some important types would be
>>    big int,
>>    big float fixed point with choosable precision
>>    8bit unsigned for array of chars
>>    could be useful u8, i8 u16 u32 etc
>>    int and unsigned fixed types
>>    types build on them as struct in C
>>    and matrices use types above 
>
>APL types are scalar, vector, array, and character.  

scalar would be int char and double of C and base types
but scalars, vector and array could be unified in matrix

>There's no "big 
>int" or "big float" or the like--APL doesn't make that distinction.  
>There are versions that let you set a flag to use native operations or 
>arbitrary-precision but that's about it.
>    
>> for the loops would be useful 
>> the if()           as in C
>> the F(;;) for loop as in C
>> the goto label primitive  G(condition, label)
>
>In general if you are looping in APL it should be setting off red 
>flags--its usually a sign that you're "writing Fortran".
>> 
>> 2) use or allow to use the return result of function
>>    for see if the function computation is ok
>>    (and not use 95% time exceptions)
>>    or better
>>    all the type has at last one bit in them

it is possible less of the above, less than one bit...
it is enought one value for example
0..0xFFFFFFFE for right value and 0xFFFFFFFF for error object
in a 32 bit variable

>>    descrive if they contain valid value and are right 
>>    and free of errors. 
>>    so the error object
>>    one object has in it one not valid value: is one error obj
>>    one object result of one function with some argument 
>>    error obj as argument: it is the error object
>
>Objects are another recent addition to APL.
> 
>> So if i print a error object it would print "Error Object"
>>  so seen that i see there is some problem,
>> and sys in every moment can check if one object is
>> right or wrong
>
>I see you're on Windows--download NARS2000 and try porting some of your 
>C code to APL, with the proviso that you always ask "how can I do this 
>without a loop".  You'll find that your APL code ends up looking not at 
>all like your C code and is usually _very_ compact.
>
>The reputation as a "write only language" comes from the tendency of APL 
>programmers at a certain stage of their development trying to write 
>everything as one liners--take an inch thick listing in C and write it 
>in one line of APL.  The information density there is so high as to 
>sometimes be impenetrable.

it is possible to write 2 significative loop{or more} in one line with
goto label too

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

#77211 — Re: Development Best Practices and C "nomenclature"

In article <fnpd5bhjfh5t6lhddcaiov2354vobb0v1a@4ax.com>, 
Ros@invalid.invalid says...
> 
> On Wed, 25 Nov 2015 18:58:53 -0500, "J. Clarke" wrote:
> >In article <ipua5b9ur7e933a7benqgc6aj8deiipdc7@4ax.com>, 
> >Ros@invalid.invalid says... 
> >> [comp.lang.apl, comp.lang.c]
> >> On Sat, 21 Nov 2015 20:49:41 -0500, James Kuyper wrote:
> >> >On 11/21/2015 06:57 PM, Keith Thompson wrote:
> >> >> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >> >>> Le 18/11/2015 17:39, Keith Thompson a écrit :
> >> >>>> Just as you can write Fortran in any language, you can write APL in any
> >> >>>> language.
> >> >>>
> >> >>> Yes, I have been doing it for decades. APL brought array processing into 
> >> >>> view. In APL everything is an array (like in Lisp lists)
> >> >> [...]
> >> >>> Yes, ignorants will scorn at APL for his famous "look": a series of 
> >> >>> greek symbols that look absolutely horrifying for the uninitiated.
> >> >>>
> >> >>> So what?
> >> >>>
> >> >>> They never understood APL. Nor do they understand it today, when they 
> >> >>> write nonsense like
> >> >>>
> >> >>> "... you can write APL in any language".
> >> >>>
> >> >>> No, Thompson, you can't.
> >> >> [...]
> >> >> 
> >> >> I admit I'm not very familiar with APL.  It has a reputation as a
> >> >> "write-only" language.  I've heard stories of 4-line APL programs
> >> >> written by experts who couldn't read their own code a day later.
> >> >
> >> >I wrote several hundred lines of APL code in 1976, didn't make any
> >> >significant use of APL for the next 20 years, and then found an old
> >> >printout of my code when I was preparing for a move. I had no trouble
> >> >reading it and understanding precisely what it did, and how. I couldn't
> >> >write such a program again without spending a good deal of time brushing
> >> >up on the language, but it was quite readable.
> >> >
> >> >> My understanding, though, is that it's a good and powerful language
> >> >> for the niche for which it was designed.
> >> >> 
> >> >> I actually didn't intend to criticize APL itself.  Rather my
> >> >> criticism was directed at, for example, C programmers who write
> >> >> excessively terse code.  "APL in any language" is not a completely
> >> >> accurate description, more of a stand-in for misusing one language's
> >> >> style in another, like writing BASIC-style C with line numbers
> >> >> and gotos.
> >> >
> >> >And the thing wrong with that statement is that APL's style is so unique
> >> >that it's virtually impossible to use that style in any other language,
> >> >so misusing it in another language just isn't an option.
> >> 
> >> i have no experience in apl, but at first see could say
> >> the problem of that language is the same of all other hll languages
> >> so C and C++ too
> >> 
> >> 1) identify the riht primitive:few operators, functions, 
> >>    loops keyword type, 
> >>    one can build easily all the remain of algorithms
> >>           (and in this C is very good)
> >>    and they would not occupy too much space in the
> >>    screen (and in this apl is good)
> >>    so each primitive instruction has to be few simbols
> >>    as F() for for(), or G for goto
> >
> >There are on the order of a hundred operators, most of which give
> 
> "hundred" operators could be too much...

I should have said "primitives".

> operators could be few on matrix... and these would be ok for vectors
> and scalar too... a litle long sentence but one understand better


>  
> >different behaviors when used monadically or dyadically, and different 
> >behaviors when used with a scalar, vector, array, or operator argumnent.  
> >Some of them do rather complicated things, especially when used with 
> >operator arguments.
> > 
> >> for example i think some important types would be
> >>    big int,
> >>    big float fixed point with choosable precision
> >>    8bit unsigned for array of chars
> >>    could be useful u8, i8 u16 u32 etc
> >>    int and unsigned fixed types
> >>    types build on them as struct in C
> >>    and matrices use types above 
> >
> >APL types are scalar, vector, array, and character.  
> 
> scalar would be int char and double of C and base types
> but scalars, vector and array could be unified in matrix

In most APLs scalar would be double.  "Unified in matrix" may work for 
some recent implementations, but in the APLs with which I am familiar 
primitives return different results for scalar arguments, for vector 
arguments, and for array arguments.
 
> >There's no "big 
> >int" or "big float" or the like--APL doesn't make that distinction.  
> >There are versions that let you set a flag to use native operations or 
> >arbitrary-precision but that's about it.
> >    
> >> for the loops would be useful 
> >> the if()           as in C
> >> the F(;;) for loop as in C
> >> the goto label primitive  G(condition, label)
> >
> >In general if you are looping in APL it should be setting off red 
> >flags--its usually a sign that you're "writing Fortran".
> >> 
> >> 2) use or allow to use the return result of function
> >>    for see if the function computation is ok
> >>    (and not use 95% time exceptions)
> >>    or better
> >>    all the type has at last one bit in them
> 
> it is possible less of the above, less than one bit...
> it is enought one value for example
> 0..0xFFFFFFFE for right value and 0xFFFFFFFF for error object
> in a 32 bit variable

In APL you can have variables with no content.
 
> >>    descrive if they contain valid value and are right 
> >>    and free of errors. 
> >>    so the error object
> >>    one object has in it one not valid value: is one error obj
> >>    one object result of one function with some argument 
> >>    error obj as argument: it is the error object
> >
> >Objects are another recent addition to APL.
> > 
> >> So if i print a error object it would print "Error Object"
> >>  so seen that i see there is some problem,
> >> and sys in every moment can check if one object is
> >> right or wrong
> >
> >I see you're on Windows--download NARS2000 and try porting some of your 
> >C code to APL, with the proviso that you always ask "how can I do this 
> >without a loop".  You'll find that your APL code ends up looking not at 
> >all like your C code and is usually _very_ compact.
> >
> >The reputation as a "write only language" comes from the tendency of APL 
> >programmers at a certain stage of their development trying to write 
> >everything as one liners--take an inch thick listing in C and write it 
> >in one line of APL.  The information density there is so high as to 
> >sometimes be impenetrable.
> 
> it is possible to write 2 significative loop{or more} in one line with
> goto label too

Which can if not carefully constructed lead to "interesting" behavior.

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

#76863 — Re: Development Best Practices and C "nomenclature"

Keith Thompson <kst-u@mib.org> wrote:

(snip, someone wrote)

>> "... you can write APL in any language".

>> No, Thompson, you can't.
> [...]
 
> I admit I'm not very familiar with APL.  It has a reputation as a
> "write-only" language.  I've heard stories of 4-line APL programs
> written by experts who couldn't read their own code a day later.
> My understanding, though, is that it's a good and powerful language
> for the niche for which it was designed.

As well as I know it, APL was originally a notation for describing
computer operations, and not intended as a progrmaming language.

The original publication of the description of S/360 is in
APL notation.

It was later that it was decided to actually use it for programming.

(snip)

-- glen

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

#77028 — Re: Development Best Practices and C "nomenclature"

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:n2skov$2in$1@speranza.aioe.org...
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, someone wrote)
>
>>> "... you can write APL in any language".
>
>>> No, Thompson, you can't.
>> [...]
>
>> I admit I'm not very familiar with APL.  It has a reputation as a
>> "write-only" language.  I've heard stories of 4-line APL programs
>> written by experts who couldn't read their own code a day later.
>> My understanding, though, is that it's a good and powerful language
>> for the niche for which it was designed.
>
> As well as I know it, APL was originally a notation for describing
> computer operations, and not intended as a progrmaming language.
>
> The original publication of the description of S/360 is in
> APL notation.
>
> It was later that it was decided to actually use it for programming.
>

ISTR that the book _A Programming Language_ was the first publication 
introducing some of the ideas of APL. This book is online can can be read 
here:

http://www.jsoftware.com/papers/APL.htm

More about APL here:

https://en.wikipedia.org/wiki/APL_%28programming_language%29


Some of us here are old enough... that we can write 4-line programs in C and 
*not* understand the code the next day!  ;-)

-- 

numerist at aquaporin4 dot com

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

#76419 — Re: Development Best Practices and C "nomenclature"

On Wednesday, November 18, 2015 at 2:50:21 PM UTC, David Brown wrote:
> 
> The reputation comes from perl scripts that are hacked together to do a
> single job.  Often this involves a horrendous regular expression or two.
>  The script makes sense at the time, with trial-and-error debugging of
> the regular expressions and the developer's notes on a scrap of paper.
> The problem comes when this throw-away script is re-used as part of a
> bigger program or a permanent feature in a system.
> 
> More serious perl code and larger programs will be as well-designed or
> badly-designed as for any other language.
>
There are other reasons
Regular expressions are difficult things to understand, and the Perl regular
expression surrounding syntax doesn't encourage a nice, clear layout.
Then there's an "array context" and a "scalar context". Once you've got
that type of dynamic typing going on, you've had it for any hope of anyone
else understanding the code, unless you make it abundantly clear what
you expect, and why.
Then some of the keywords write to a variable called "_". That's right. Underscore.
That's just hopeless.

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

#76428 — Re: Development Best Practices and C "nomenclature"

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Then some of the keywords write to a variable called "_". That's
> right. Underscore.  That's just hopeless.

It's called $_, not _.  (No, it's not "hopeless", but this isn't the
place to discuss it.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#76434 — Re: Development Best Practices and C "nomenclature"

On 11/18/2015 09:50 AM, David Brown wrote:
> On 18/11/15 00:45, James Kuyper wrote:
>> On 11/17/2015 06:07 PM, Ian Collins wrote:
...
>>> I thought all Perl programs were potential IOCCC entries...
>>
>> I often wondered where this stereotype comes from. Most of the perl
>> scripts I've seen are no worse than typical C or C++ programs in this
>> regard. I'm sure it's possible to obfuscate perl code at least as badly
>> as you can obfuscate C code, but serious professionals don't do that,
>> and there's nothing about perl that forces or even encourages you to
>> write such code.
>>
> 
> The reputation comes from perl scripts that are hacked together to do a
> single job.  Often this involves a horrendous regular expression or two.
>  The script makes sense at the time, with trial-and-error debugging of
> the regular expressions and the developer's notes on a scrap of paper.
> The problem comes when this throw-away script is re-used as part of a
> bigger program or a permanent feature in a system.
> 
> More serious perl code and larger programs will be as well-designed or
> badly-designed as for any other language.

That would explain it then - most of the perl code I have to deal with
is part of a production system that will typically execute the script
once every five minutes, 24 hours a day, 7 days a week, 365 days per
year. "hacked together" doesn't even come close to being an accurate
description.
It does use regular expressions, but that's reasonable given the
context; if it were written in C, it would almost certainly have made
use of regex() - and the code would have been a lot more complicated.

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

#76623 — Re: Development Best Practices and C "nomenclature"

David Brown <david.brown@hesbynett.no> wrote:

> On 18/11/15 00:45, James Kuyper wrote:
> > On 11/17/2015 06:07 PM, Ian Collins wrote:
> >> Richard Bos wrote:

> >>> Would you? I wouldn't expect them even there. The only place they ought
> >>> to be found is the IOCCC. Or a Perl program.
> >>
> >> I thought all Perl programs were potential IOCCC entries...
> > 
> > I often wondered where this stereotype comes from. Most of the perl
> > scripts I've seen are no worse than typical C or C++ programs in this
> > regard. I'm sure it's possible to obfuscate perl code at least as badly
> > as you can obfuscate C code, but serious professionals don't do that,
> > and there's nothing about perl that forces or even encourages you to
> > write such code.
> 
> The reputation comes from perl scripts that are hacked together to do a
> single job.  Often this involves a horrendous regular expression or two.
>  The script makes sense at the time, with trial-and-error debugging of
> the regular expressions and the developer's notes on a scrap of paper.
> The problem comes when this throw-away script is re-used as part of a
> bigger program or a permanent feature in a system.
> 
> More serious perl code and larger programs will be as well-designed or
> badly-designed as for any other language.

And IME James should consider himself lucky; most Perl programs I've
seen are in the former category. It is, after all, what Perl is for: AWK
on steroids - and, IMAO, crystal meth.

Richard

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web