Great question!
> So, how would you write an configuration file parser in J, if clarity were
> an important concern?
I find it helpful to identify the audience when writing - code or
non-code. I then try to write for the audience. If there won't be an
audience other than a computer and I will never read it again, then
I'm not so worried about clarity. Otherwise, it's a real concern. My
audience typically includes a lot of imperative/procedural
programmers. I don't know if that's completely due to experience or
how brains are actually wired for some people. I just know that's what
I learned growing up. It's stuck with me for 20 years. I think of
myself as a logical, "step by step" thinker.
As such, I would probably write it in a style that scans the lines and
acts upon the lines. I think the PicoLisp example is close to how I
would write it. As an aside, I have a few years of experience with
PicoLisp
(de rdConf (File)
(pipe (in File (while (echo "#" ";") (till "^J")))
(while (read)
(skip)
(set @ (or (line T) T)) ) ) )
Or I would get clever and translate the config file into something
that can be evaled in the native language
If I compare that to the your J implementation
> deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&' =')&>@(#~
> a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)
This J implementation feels more like code golf or a compressed
string. How many tokens/operations are included in it? I won't count,
but I am fairly sure it's more than the (pipe, in, while, echo, till,
read, skip, set, or, line) 9 in the PicoLisp example.
When reading a long J string or an entry in the obfuscated C code
contest, I try to recognize patterns or operations. Having used J for
about 6 months, I can recognize probably about half the operations in
that string without having to look them up. That's progress. It still
feels like a "run on sentence" which is harder to read than short
sentences.
> and it's going to take more work to
> make it readable than it took to make it actually work".
That's normally true for any type of writing. The difference between a
first draft and final version is a fair amount of work. Taking a
stream of consciousness and turning it into something other people
understand takes some effort.
I think there's a fine balance between tacit expressions and clarity.
It may be my level of inexperience with the language. However, I
wonder if I've put as much time on it as any intro-level APL
programmer. Are there any conventions in the language for # of tokens,
trains, etc for a readable sentence? There might be some relation to
phone numbers and the Magical Number Seven, Plus or Minus Two [1] of
the number of objects a brain can hold in working memory. That J
expression exceeds it for me as my brain tries to parse it
[1] - http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
On Mon, Jan 13, 2014 at 1:45 PM, Dan Bron <j...@bron.us> wrote:
> We often say the APL family of languages allow us to use language as a tool
> of thought. How does this play out in practice? Do we approach reading J
> programs differently from those written in other languages? If so, how?
>
> These questions occurred to me today while I was knocking together an
> implementation of a RosettaCode task on reading configuration files. The
> task is to parse file formatted like the following:
>
> # This is the fullname parameter
> FULLNAME Foo Barber
>
> # This is a favourite fruit
> FAVOURITEFRUIT banana
>
> # This is a boolean that should be set
> NEEDSPEELING
>
> # This boolean is commented out
> ; SEEDSREMOVED
>
> Fuller example at [1]. After reading the intro, I copy/pasted the example
> into a J noun and proceeded to write this:
>
> deb L:0@:(({.~ ; [: < [: ;^:(1=#) ',' cut (}.~>:)) i.&1@:e.&' =')&>@(#~
> a:&~: > ';#'e.~{.&>)@:(dlb&.>)@:(LF&cut)
>
> Which is a verb which takes the configuration text as input and produces a
> table of name-value pairs as output. My first thought was "wow, I was able
> to knock that together in literally less than a minute, through simple
> incremental iterations in the REPL: J is AWESOME".
>
> But then, thinking about posting it, I realized "this is awful, no one's
> going to be able to read it like this, and it's going to take more work to
> make it readable than it took to make it actually work".
>
> So that got me thinking about what exactly we mean by J as a notation. And
> I wondered: how could we use the language to express our thoughts more
> clearly, and how does that differ from how we write J when we just want to
> get something done? And is this a different or more difficult problem for
> J than other languages?
>
> So, how would you write an configuration file parser in J, if clarity were
> an important concern? I'm interested in not only the actual program, but
> the reasoning behind the decisions you make.
>
> -Dan
>
> [1] RosettaCode task to read a configuration file:
> http://rosettacode.org/wiki/Read_a_configuration_file
>
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
