Björn Helgason wrote: > Does it really matter what APL I don't see how the implementation of APL could not be an issue.
> "The only problem is that if you take abstraction to its > ultimate conclusion, you get a language like APL which, > except for some niche applications, failed dismally because > it became too difficult to work with." All computer languages are difficult to work with. Math is hard. Etc. As a general rule: unless you understand the subject, it's hard. > Many(/most?) people think J is difficult too. Sure. And some think it's rather simple. This does not seem to be a reflection on the "level of education" of the person expressing their point of view -- it seems to have more to do with how the subject is being presented. Also, it has to do with what the person is trying to do. Translating a program from some other language non-array language to J and getting it to work efficiently often seems hard, to me. Writing such programs from scratch is often easier than translating it. In contexts where I can influence the requirements to make the J implementation easier, writing such programs from scratch tends to be especially easy. In contexts where the requirements have already been influenced to make the implementation fit better in the other language, translating the program to work efficiently in J often seems harder. I'd classify those difficulties as a reflection on the differences in how such systems are architected. > No matter how hard we point out how easy it is they > do consider it too hard and give up. Right -- because pointing out how easy (or hard) something is doesn't convey much objective information. It's mostly a comment on the observer's comprehension of the subject. > Many in c.l.a complain J is too hard to read or write. Again, that's fine. I imagine many of them have some installed base of APL code and what they're really commenting on is how much work they'd have to do to shift their tools and applications from the one environment to the other. No matter what programming language (or human language) you want to talk about, there are going to be people who choose not to use it. People are allowed to make their own choices. If your interest is in growing the J community, you should instead focus on expressing useful concepts in the context of the language, helping people out who are in a position where J can do something useful for them, that kind of thing. > The real challenge is to find out why they find it so > difficult and see if it would be possible to make it > easier. That could certainly be challenging. But that's not the same thing as being a fruitful approach. I certainly agree that awareness of such issues can be a useful thing, but that's a broad category (including things like "I've spent 30 years learning the subtleties of XYZ APL and I don't think I'll live another 30 to learn J" and "Our budget for this year is already committed" and "We've already hired a half dozen programmers, and I don't want to have to deal with replacing or retraining them" and so on...). If you want to understand other people's issues, you need to start by understanding that they're not going to describe everything that goes into their decisions at the drop of their hat. People generally comment on some local event which best represents, to them, the body of concepts they're currently working on. If you just latch on to some quip, like "J is hard", you'll usually be ignoring most of what they care about. Which is fine -- you aren't under any obligations to live other people's lives for them, or even to be helpful to them. On the flip side, if you're not offering anything relevant to their context, it's all right for them to ignore you. > I have always thought that we need books like "J for > Dummies". I would write one if I knew how. Well, the first step would be to write a rough draft, or outline. (Outlines are more viable where you have an idea of the scope of the project but aren't sure where to spend your energy. Drafts are more viable where you have a good idea about where you want to spend your time and energy.) > I guess I am beyond seeing what challenges a Dummy might > face trying to learn J. I guess most of us are. Nah... I've seen a high school dropout pick up some J rather easily in the course of a half an hour. It's easy to understand stuff like: x=: 123 x 123 i.10 0 1 2 3 4 5 6 7 8 9 x=: i.10 x 0 1 2 3 4 5 6 7 8 9 x+100 100 101 102 103 104 105 106 107 108 109 if you can see it happening. > Like reading this article that he is giving an answer. > "Things that conceivably might take dozens or hundreds > of lines of code in a lesser programming language really > could be done in *one line* of APL. I've seen it done. > It kind of convinced me I'd never be able to do that kind > of work, I don't have the background." That sounds like the use of a feature like matrix division. That can be taught (and you can learn to use matrix division for curve fitting, or the like, without having to understand everything you'd learn in a semester of linear algebra). Then again, skilled mathematicians tend to have an advantage in any programming language. On the flip side, consider the popularity of C and consider how hard C can be. See also: http://www.ioccc.org/winners.html > I guess many people like that give up before trying or after > just a short test. The entry barrier seems to be too high. I guess I just disagree. There certainly are issues that could make J easier to work with. (I'd like to be better support for writing programs designed to be used from the unix command line, for example. I'd also like to see built in support for interactive tooltips in J's portable graphics environment.) But coming up with good (long lasting aka "elegant") approaches for these contexts takes some thought and skill. > In my opinion J does not have as a big hindrance as APL in > general does. Having left out a lot of APL failings. Sure -- J programs are much easier to email than APL programs, for example. > Also having many good labs, demos and helps. I agree. > Even so it does seem to be hard for many to start using J. If you want to pursue that, I'd find useful ways of getting people to use J without having to commit much effort (to learning it, or learning the environment.) Those are the contexts where it's easy for people to start using J. > Quite a lot of people may get scared off by trying to do > some advanced things before they have managed to learn > the basics. Right. In general, it's easiest to pick up a programming language in a social context -- where that programming language helps you communicate (or otherwise interact) with other people. Whether that's immediate ("instant message") communication, or some elaborate thing you wind up showing someone later (maybe art work), the point is that the programming language and environment has to mesh with something a person would be doing anyways. > I guess the real basics are very easy but the step over to > do some simple things with data from the outside and doing > presentations and printing may be to big of a step for the > newbie in many cases. Ok. Putting together a good presentation can take quite a bit of time and effort, and generally people interested in doing so want to have a good idea of where they're going and what kinds of effort it's going to cost them before they commit to a course of action. So, I think I agree with you on this point. > I guess the grid tools will be a big help in getting > newbies hooked. For newbies that want grid tools, I imagine it will indeed be a big help. > I think we are getting there but slowly. Sure. > Easy tools to operate the web would be great. Ok. That's an extremely broad topic. And some of the implications a person could take from that topic seem rather open ended ("J should parse javascript", for example). Don't try to do everything -- you'll never get it all done. -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
