I like hooks too. I use
ux_vy =: 2 : '(v~ u)~' NB. (u x) v y
What I prize in code is good commentary that explains why the programmer
did what they did, what alternatives were attractive and why they were
dismissed, and how it is guaranteed that the chosen solution solves the
problem. The executable code sequence is secondary; a programmer who
understands the problem well enough to write good commentary usually
comes up with a pleasing expression of the solution.
Henry Rich
On 8/20/2020 11:09 PM, David Lambert wrote:
Likewise, I try to avoid sameness. Code sprinkled with [ and ] may as
well contain x and y . Consequently I make heavy use of hooks and
left hooks (u~ v)~ . The community considers these stinky. Avoiding
same also leads to trains beginning (that is, the right hand side)
`noun&verb)' rather than `noun verb ])' . Frankly the white space
with same is visually pleasing. Bondage displeases me.
Are long trains stinky? Dr. Ken Iverson's examples in the
documentation are of short named clear trains.
Pure tacit code Pepe style contains a lot of {:: extractions from the
state array. Sometimes I name these, ie.`coefficients=: 7&{::' .
This seems retrograde. Certainly you've seen those old FORTRAN
programs where the angry programmer substituted all variables as
indexes into a single array? I've recently started to learn the
locale system and discovered how to hide these names in a private
namespace, thereby converting the acclaimed pure functional program
into "programming by side effect". For instance we can chain @:([
sideeffect__locale)@: into the sentence.
Date: Thu, 20 Aug 2020 19:24:01 +0900
From: ethiejiesa via Programming<[email protected]>
To:[email protected]
Subject: [Jprogramming] Code smells in J
Message-ID:<[email protected]>
What are some classes of code smell in J?
For clarity, "code smell" means any characteristic of source code that
indicates a potentially deeper problem. These are anti-patterns that
occur at
the source code level.
The canonical example is probably duplicated code, which indicates a
potential
for abstraction or merging of the repeated code. In C-like languages,
deeply
nested if statements are typically considered smelly, suggesting a
potential
need for better data structures, separation of mixed concerns, etc.
In haskell
"boolean blindness" is another.
When writing tacit verbs, I find that trying to avoid ("), ([) or
(]), and
parentheses as much as possible often helps me find better solutions.
That's
what prompted this question.
Anyway, what are similar code anti-patterns in J (or APL) that have
helped you
write better J by recognizing and avoiding them?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
This email has been checked for viruses by AVG.
https://www.avg.com
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
