Here's deb without @ and &
deb
#~ (+. (1: |. (> </\)))@(' '&~:)
deb2
#~ ([: (+. (1 |. (> </\))) ' ' ~: ])
However it seems as though there should be a better explicit version than:
f=: 13 :'(#~[:(+. 1 |. (> </\)) '' ''~:])y'
Linda
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Linda Alvord
Sent: Sunday, July 13, 2014 11:43 PM
To: [email protected]
Subject: Re: [Jprogramming] Design goals readability and writeability?
I enjoyed your article:
<"1 toupper"0>"0;:'alpha beta gamma'
┌─────┬─────┬─────┐
│ALPHA│BETA │GAMMA│
└─────┴─────┴─────┘
Linda
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ian Clark
Sent: Sunday, July 13, 2014 9:40 PM
To: [email protected]
Subject: Re: [Jprogramming] Design goals readability and writeability?
"The alleged unreadability of J - and what to do about it"
http://www.jsoftware.com/jwiki/Vocabulary/Unreadability
On Sun, Jul 13, 2014 at 11:43 PM, Don Kelly <[email protected]> wrote:
> Absolutely!!
> J suffers from the same problem as its precurser APL- in spades.. One can
> write very terse code because of its power. Often, 6 moths later the
> original writer has to spend time interpreting what was written. I have
> come up with some terse code and , more often terse code from others- all
> of which has been put in a utility script wrapped in comments so that when
> I want to use it-I do have such guidance. This is something one has to do
> to a great extent with any programming language. It is even more important
> with J tacit.
>
> Don Kelly
>
>
> On 12/07/2014 11:44 AM, Don Guinn wrote:
>
>> Readability depends on a person's background. I can't read Chinese. Does
>> that mean it's not a readable language?
>>
>> When writing a program or a document one must assume some level of
>> knowledge of the reader. J tends to assume readers have a greater
>> knowledge
>> of mathematics than most other programming languages require.
>>
>> But readability is a real problem. What is usually missing from many
>> programs, especially J tacit, is the intent of something. Say I see
>> something like this:
>>
>> < @ (({. + i.@{:)@[ { ] )
>>
>> It would certainly help to have some idea what this is supposed to do.
>> What
>> its arguments are and what it returns. Documentation really helps.
>>
>> But J expressions can be intimidating. It has always bothered me that I
>> could attack a FORTRAN program spanning several pages comfortably. But a J
>> program of just a few lines which do exactly the same thing is hard for me
>> to get into.
>>
>>
>> On Sat, Jul 12, 2014 at 12:23 PM, Erling Hellenäs <
>> [email protected]>
>> wrote:
>>
>> Hi all !
>>>
>>> Yes, maybe we should all be concerned about writing readable code instead
>>> of the shortest and most cryptic code? Maybe we should also write
>>> writeable
>>> code? Find a way to write that allows us to get the expressions right the
>>> first time?
>>> J is more of a notation than a language? The value of a notation is
>>> determined by clarity, but also readability? Maybe readability and
>>> writeability, in the sense I explained above, should get higher priority
>>> as
>>> design goals for our future J?
>>>
>>> Cheers,
>>>
>>> Erling Hellenäs
>>>
>>>
>>>
>>> On 2014-07-12 07:40, Raul Miller wrote:
>>>
>>> I would not generalize to higher rank arrays without a model of why I'd
>>>> be
>>>> using them.
>>>>
>>>> In other words, v=: {"_1 |:~&0 2 is probably good enough.
>>>>
>>>> There are some interesting contradictions here - while one needs to be
>>>> comfortable thinking mathematically to get decent performance out of a
>>>> system, usually what we are building is a mix of instant and delayed
>>>> gratification and we usually assume our audience has no direct interest
>>>> in
>>>> the math we are performing (indirect interest, yes - sometimes).
>>>>
>>>> Often I think we go overboard, and we should throw back in some exposure
>>>> to
>>>> some of the more robust concepts (especially for the kids, so they have
>>>> something interesting to play with). But professional adults tend to be
>>>> under a lot of time pressure, and as a result their needs often seem to
>>>> be
>>>> a mix of the very basic and the childish.
>>>>
>>>> Meanwhile, it seems like anything worthwhile takes time and effort.
>>>>
>>>> Anyways, professional software design often centers around use cases and
>>>> similar models which are aimed at extracting the important concepts
>>>> about
>>>> what people need to get done and how they want to work. And that kind of
>>>> information is what you need if you are going to properly generalize
>>>> application code.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>> For information about J forums see http://www.jsoftware.com/forums.htm
>>>
>>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
