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

Groups > comp.lang.postscript > #1887 > unrolled thread

Synonyms for mark: to use or not to use

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

Contents

  Synonyms for mark: to use or not to use jdaw1 <jdawiseman@gmail.com> - 2014-05-07 06:05 -0700
    Re: Synonyms for mark: to use or not to use luser- -droog <mijoryx@yahoo.com> - 2014-05-07 13:25 -0700
      Re: Synonyms for mark: to use or not to use jdaw1 <jdawiseman@gmail.com> - 2014-05-08 01:26 -0700
        Re: Synonyms for mark: to use or not to use luser- -droog <mijoryx@yahoo.com> - 2014-05-08 16:16 -0700
          Re: Synonyms for mark: to use or not to use jdaw1 <jdawiseman@gmail.com> - 2014-05-09 01:53 -0700

#1887 — Synonyms for mark: to use or not to use

It seems that at least on regular contributor to comp.lang.postscript uses [ for several of the different uses of mark. For example, a recent post contained
	[ ... >>

My practice is to make brackets match, as that allows my text editor to select out to matched parentheses with command-B. So my code contains the likes of
	[ ... ] 
	<< ... >>
	mark ... pdfmark
	mark (String ) number (; string ) number (.) ConcatenateToMark

Is there authoritative best practice? What do others do?

[toc] | [next] | [standalone]

#1888

On Wednesday, May 7, 2014 8:05:59 AM UTC-5, jdaw1 wrote:
> It seems that at least on regular contributor to comp.lang.postscript uses [ for several of the different uses of mark. For example, a recent post contained
> 
> 	[ ... >>
> 
> My practice is to make brackets match, as that allows my text editor to select out to matched parentheses with command-B. So my code contains the likes of
> 
> 	[ ... ] 
> 	<< ... >>
> 	mark ... pdfmark
> 	mark (String ) number (; string ) number (.) ConcatenateToMark
> 
> Is there authoritative best practice? What do others do?

My own preference to use [ for all marks comes from my
interest in code golf. If the goal is reducing the length
of the source, then it's the clear winner.

In other domains, it might be considered to be less readable.
So where readability is the goal, I would use matching 
constructs with proper indentation.

If the goal is didactic, or intended to teach about the
language, then it might be best to swing the other way,
forcing the audience to ask questions!

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

#1889

Code golf, eh? I hadn't thought about that. For my taste legibility is much more important (as well as speed, memory usage, &c.).

The argument about teaching is interesting, though there is also a case that teachers should teach students to write legible maintainable code, and do that partly by example. Here, at comp.lang.postscript, without live teacher-student interaction, legibility also meritorious.

Anyway, I have not been dissuaded from my current practice.


Note: original post has "on" where "one" was meant.

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

#1891

On Thursday, May 8, 2014 3:26:34 AM UTC-5, jdaw1 wrote:
> Code golf, eh? I hadn't thought about that. For my taste legibility is much more important (as well as speed, memory usage, &c.).
> 

I'm not sure I can adequately explain the appeal of code-golf
to those who don't already believe. (I've failed on numerous
occasions with the regulars of comp.lang.c.)

But for fodder, here's a Lindenmayer-System program where the
engine reduces to 255 chars without comments. (more explanation
at http://codegolf.stackexchange.com/a/10927/2381)

%!
[                     %begin dictionary construction
    % productions are described by integer-key/string-value pairs
    48(0+1F) %0       %ascii code for '0' defined as the string "0+1F"
    49(F0-1) %1       %  "     "   "  '1'   "     "   "    "    "F0-1"
    43(+) %+          %  "     "   "  '+' defined as itself
    45(-) %-          %  "     "   "  '-'   "     "   "
    70(F) %F          %  "     "   "  'F'   "     "   "
    % parameters
    /A 90 %angle
    /R 2  %radius
    /B 10 %maximum recursion-level
>>begin  % L-system dictionary on top of dictstack
(F0)     % initial string on stack
300 400  % starting position on stack


/*{<920>dup 1 4 3 roll put cvx exec}def/${//* 73 *}def %73=forall
[/T[70{R 0<85>$}48{}49{} %<85>=rlineto
43{A<88>$}45{A<6e88>$} %<88>=rotate <6e>=neg
91{<1e39>$ %<1e>=currentdict <39>=end
    [/.[<286827>$]cvx>> %<28>=currentpoint <68>=matrix <27>=currentmatrix
        <0d0d>$} %<0d>=begin
93{.<9c6b1e39390d>$}>> %<9c>=setmatrix <6b>=moveto
/S{dup B eq{T<0d3e>${<643f>$}<4939>$} %<3e>=exch <64>=load <3f>=exec <49>=forall
{exch{<643e>$ 1 add S}73 *}85 * 1 sub}>>
<0d6b>$ 0 S<a7>$  % 85=ifelse <a7>=stroke


> 
> The argument about teaching is interesting, though there is also a case that teachers should teach students to write legible maintainable code, and do that partly by example. Here, at comp.lang.postscript, without live teacher-student interaction, legibility also meritorious.
> 

Indeed. And perhaps "mark" for everything would actually be
best for that goal, anyway.

> 
> Anyway, I have not been dissuaded from my current practice.
> 

Not a problem. If you can better defend your preferences with
well-reasoned arguments than before, then my efforts will have
been worthwhile.

-- 
freethink

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

#1894

Code golf does seem like an excellent intellectual exercise, honing understanding of problem and language. And, like all such problems, a pleasure of itself. But in the real world, the scarce resource is not an extra few hundred bytes of code; it is the programmer's time, best conserved by legibility (and also matters of CPU and memory, of course).



> > Anyway, I have not been dissuaded from my current practice.

> Not a problem. If you can better defend your preferences with
> well-reasoned arguments than before, then my efforts will have
> been worthwhile.

Thank you, they have been worthwhile. Partly by explaining your coding preferences.

[toc] | [prev] | [standalone]

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

csiph-web