J/HouseStyle: Difference between revisions
no edit summary
(→{{header|J}}: regarding multiple alternative solutions (e.g. tacit vs explicit)) |
No edit summary |
||
Line 130:
::I've got a bunch more that don't occur to me immediately. But I'm interested in what you (and others) have to say. As I said, this is not as important to me as "big picture" style and formatting -- I still want to allow individual authors to express their own styles. --[[User:DanBron|DanBron]] 21:51, 10 December 2009 (UTC)
== Meta issue: "converts" ==
Personally, I am slightly bothered by the idea that we are trying to gain "converts".
In part, I think this misses out on some of J's strengths. But, also, I am bothered by the implications.
But, first: when you are working with other people, you need to spend some time using their language. This means that some of the most productive uses of J will probably be multi-lingual uses. I am sure we can all come up with some good examples of this, but Javascript in browsers is probably a fairly common case, this year.
Second, J has some strengths that become stronger when used in the context of developing programs in other languages. In particular, J pushes "control structure issues" into its expressions, and refactoring code -- and re-architecting code -- often winds up being a set of relatively minor changes in a J program. In other words, J can help us reason about program architecture by making experiments easy. If we are working purely in J, this issue is of course important: sometimes we can only gain reasonable performance from a program by re-architecting it to work around issues introduced by the interpreter. However, various other languages make architectural changes difficult and some significant number of projects could benefit from an architectural exploration phase even when the target language is not suitable for that task and yet can not be changed.
Third, historically speaking J evolved from notation which was intended to convey ideas and teach people about computing. J suffers and benefits, of course, from the ugliness and ubiquity of ASCII. Nevertheless, it seems to me that J has some serious potential, for conveying ideas about programs. But I feel this potential gets lost in the noise when we focus on "J as the way to do things" rather than using J to present concepts as clearly as possible. (And I am probably just as guilty of this mistake as anyone else.)
Of course, for some people and for some projects, J is the right tool and I do not want to take anything away from that. And, almost certainly, some projects which do not currently use J could probably benefit greatly if they did. And, sometimes a small bit of J code you can write up in an hour or so might outperform code that takes months or years to write in another language. But I think that if we try and pretend that J should always be the right tool for the job that we diminish both the J community and the other communities we can participate in.
Essentially, when we make J as disposable as we can, we wind up creating situations where people can choose J on its merits rather than because of some other issue.
So, what does this mean for J's House Style? I am not completely sure. But perhaps a good start would be to call out a handful of "decent examples of good presentation of ideas, using J" -- to put some emphasis on the conveying of concepts, where it belong.
--[[User:Rdm|Rdm]] 17:21, 24 May 2010 (UTC)
| |||