NYCJUG/2009-09-08/PromotingJOnRosettaCode
Dan Bron recently made this successful request of the J community:
Rosetta Code Invitation . from Dan Bron <j@bron.us> . to Programming forum <programming@jsoftware.com> . date Thu, Aug 27, 2009 at 9:22 AM . subject [Jprogramming] RosettaCode . Hey all,
I encourage Forum members who haven't contributed to RosettaCode to do so. There are approximately 200 tasks on RC that need J solutions:
http://rosettacode.org/wiki/Tasks_not_implemented_in_J
. A lot of these tasks are not amenable to J solutions, and could be "addressed" by simply entering Template:Omit from to the task in question. Others are problems already solved in J (Bulls and Cows, Monte Carlo), which could be addressed by simply linking to the J wiki. If you see tasks of this sort, just jump in and make the small edit. But many of the tasks require a true J solution.
. There are no rules or strict guidelines for J solutions, but it would be nice if we could highlight features that differentiate our language. In particular brevity (so we stand out during a quick scan of the page). But also tacit (point-free) code, calculus of functions, etc.
. But the first goal is to get greater coverage on RC; we can always polish the solutions later. So just pick a task and solve it, don't worry about how "good" the solution is, so long as it matches the spec.
. For you APL/K/Q etc fans, those languages could also use some coverage (I started a brief APL campaign, but gave up pretty quickly). If you're a member of an APL/K/Q forum, you might consider posting a message similar to this, there.
. It's really time to start marketing our language.
-Dan . PS: For those of you who already contribute to RosettaCode, could you please "register" yourself at . http://rosettacode.org/wiki/Category:J#Jers_on_RosettaCode ? . I've been doing it so far, but it's hard for me to keep up and give due credit (I have to troll through changes seeking instances "header|J" or "added J" etc which is a laborious process).
Reply: Sherlock, Ric <R.G.Sherlock@massey.ac.nz> . I agree that J contributions to the site have the potential to be a powerful marketing tool for J (and its cousins) and kudos to especially Tracy and yourself for the effort you've put in. . I also agree that problem coverage is important, but am not sure that it should be at the expense of quality. Showcasing the brevity & power of the language should hopefully get people's attention, but I think it is also important to show how that brevity and power makes problems (and code) "simple". . In my opinion we need to beware of intractable one liners which although they may attract attention, it probably won't be positive, or encourage further exploration of the language. . Take the entry for "Index in a list" as an example:
H ;:^:_1@(](>@{:@]|."_1(,.>@{.))i.({;(~:_1+#))1|.'is not in haystack';":&.>@i.@#@[) N
Washington is not in haystack
4 Bush
I'm sure most people's first reaction looking at that line will be to wonder that anyone or anything could make any sense of it! The following doesn't do quite the same job but (to me anyway) looks less daunting at first glance.
Haystack ;:^:_1@(] ,. [ ((<'is not in haystack')"_)`(#@[ I.@:= ])`(8!:0@])} i.) Needle Washington is not in haystack Bush 4
But maybe a better way to show the same code would be as follows:
msg=: (<'is not in haystack')"_
idxmissing=: #@[ I.@:= ]
fmtdata=: 8!:0@]
Haystack ;:^:_1@(] ,. [ msg`idxmissing`fmtdata} i.) Needles
Washington is not in haystack
Bush 4
It is still way more concise than most of the other languages' entries!
. So I'd encourage people to add to the current problem coverage not to worry too much about perfect solutions if they'd rather move on to the next problem, but I'd also encourage those who'd prefer to polish to do so as well.
...
Matthew Brand had this good idea to offer.
Reply: Matthew Brand <mtthwbrnd@googlemail.com> . Rather than just responding to algorithms already posted in other languages, there are a few (many?) good showcases of practical J use in the documentation/jwiki which are already well written.
E.g., the Knight's Tour algorithm might be a good showcase of J: http://www.jsoftware.com/jwiki/Essays/Knight's%20Tour
It would be interesting to put new tasks up where J will come out really well compared to other languages. I did not want to put the KT up though since it is not mine.
...
Part of an exchange in which Dan admits to some bad behavior and Ric draws a lesson from it for all of us:
Reply: Sherlock, Ric
. > From: Dan Bron . > Most of the "excessively terse" J code on RC is my fault. I actually . > wrote up an email explaining why I prefer this format, but it disappeared in . > the ruins of my failed HDD this weekend. . I can understand that you might prefer that format for your own use. I know that when I'm developing I often end up with big long lines of code. It is not unless I plan on coming back to it or showing it to someone else that I take the next step and break the line up into smaller more manageable chunks.
I just think that we'll have more chance encouraging others to give J a go, if we don't make it appear more daunting than it has to be.
A typically well-considered contribution from Raul:
Reply: Raul Miller
On Mon, Aug 31, 2009 at 4:44 PM, Sherlock, Ric<R.G.Sherlock@massey.ac.nz> wrote: . > Note that the original comment was made here: . > http://rosettacode.org/wiki/Talk:Basic_bitmap_storage#Amount_of_comments . I have added a section to that talk page, describing the algorithm at an introductory level. Their talk pages seem like the right place for this kind of exposition. . (I also modified the implementation, slightly, to make it easier to document.) . To some degree, I think we should treat criticisms of J's readability as calls for help. And, I think we should treat generic criticisms like vague bug reports -- something to be polite about, but something where they need to put in some additional effort before it really means anything.
These suggestions about making J more attractive fit in with ideas about "domain-specific languages" and "little languages" that have found favor elsewhere.