Bravo, Alex. These are the right questions you're asking. And -- yes
-- I too liked Bo's suggestion.
A "training wheels" form of J, tailored to people who know BASIC,
would be so easy to write. Plus its accompanying textbook (essential
to write, if not to read). But it really would need testing on
bona-fide beginners, to see whether the shells are landing on-target.
When I first came to J, I was dismayed at its alien-ness. So
unnecessary, I thought. A glance inside the _z_ locale convinced me
this was implicitly recognised, if not publicly admitted. Years later,
J now seems perfectly natural to me, and I'm shocked at my past
attitude.
But "users can get used to anything", a respected ergonomist assured
me once. "They kiss the whip. They grow to love the systems they are
forced to use". (That's not me, of course. Oh no no no :-)
The need for "training wheels" soon goes away. Gradually. Any
programmer is amenable to the invitation "ok now, wouldn't you like to
get rid of an inessential layer...?" I still habitually use smoutput,
inv and each, instead of 1!:2, ^:_1 and &.>, but I no longer have much
use for pick, rows and define.
Once upon a time, "implementation languages" (ILs) were in fashion.
The idea was that every problem domain, like linear algebra or
electronic circuitry, had its own domain-specific language, or IL,
typically residing in a library of subroutines. The thing to do (so
the idea ran) was to write an app (starting with J, say) in 2 clear
stages:
J --> IL --> app
Most developers do this automatically, though unconsciously and
unevenly. The proponents of the idea wanted to systematise it,
especially for developer teams. Also for "courseware", eg a sandbox to
support a course called: IT for electrical engineers, or IT for
biology technicians (two actual examples I used to teach.) Such
courseware would then face becoming a standard in education, acquiring
its own bestseller textbooks. In the UK in the 80s, the govt actually
put money behind organisations like BECTa to promote some of the more
successful ILs. These were typically originated by some university
dept of education, in cooperation with one or two trial schools.
I mention all this just to say that J is a super language for
implementing an IL. Even better than APL and FORTH (not forgetting the
C preprocessor!) -- and these lend themselves to writing an IL far
better than most of the leading industry languages. Typically an IL
"primitive" is defined in a single terse line, eg:
rfd=: 180 %~ o. NB. Radians from degrees
sin=: 1&o.
SIN=: sin@rfd
making the given IL easy to publish, and distribute to students.
On Sat, Dec 1, 2012 at 4:14 AM, Alex Giannakopoulos
<aeg...@blueyonder.co.uk> wrote:
> On 30 November 2012 16:17, Bo Jacoby <bojac...@yahoo.dk> wrote:
>
>> J is a rich language, and it might be a good idea to define an elementary
>> subset for beginners.
>
>
> Couldn't agree more.
> A simple startup configuration file. Define verbs for trig functions so
> they don't look stupidly arbitrary.
> Some other elementary functions too, like polar2rect and rect2polar
> conversions that act on vectors (none of this xfy binary stuff here
> please), you know, stuff like you can find on *calculators*.
> Define dot-product, matrix-multiplication, cross-product, determinant, etc,
> as user-friendly built-in verbs. When I am a beginner, I DO NOT, repeat
> NOT want to know about the . operator at the level of the jdict, it is a
> highly advanced subject, intriguing - yes, but not for newbies. Yet I do
> want to do matrix ops. I was told this was a language for linear algebra.
> It would probably be a good idea, then, if we could do some linalg -
> straight out of the box - without serious brain damage. I have had abuse
> hurled at me by math teachers who have seen J's linalg primitives (LOL).
> Add some nice libs for equation solving while we're at it. Simultaneous
> and also some numeric solvers. This is what people want. A language, not
> an assembler for a language.
>
>
>> J is a nice calculator for elementary computations. You can do a lot of
>> computing without knowing anything about binomial coefficients and taylor
>> expansions and capped forks.
>
>
> Agree with the first two, NO way on the third. Even the 13 verb gives you
> capped verbs, there is no way to begin learning J without it. Also they
> solve the problem of having to figure if you should use At or Atop,
> invaluable for a beginner who hasn;t quite mastered rank yet.
>
> This problem, which once again gives rise to a long thread, could easily be
> solved by a highly visible Programming FAQ page, with lots of links to.
> Deal with capped forks, @ and @: and why you can't have things like +/ a
> b c You know, the questions people *keep asking*. Remove ancient
> irrelevant stuff like the use of x. and y. We are not at J401 any more.
>
>
>> If you need to understand everything in order to be happy, then you may be
>> unhappy. I taught my son elementary APL when he was 10 years old, and he
>> loved it!
>>
>
> Would he have been just as happy at 14 when he had to use the cosine rule
> to solve a triangle? Would he really prefer
> cosrule_getang =: 13 : '_2&o.(((+/*:}.y)-*:{.y) % */ 2, }.y)'
> or
> cosrule_getang =: [: _2&o. (([: +/ [: *: }.) - [: *: {.) % [: */ 2 , }.
> to
> cosrule_getang := (Aa,B,C) -> acos((B^2+C^2-Aa^2)/(2.0*B*C));
> Just wondering...
>
> These are simple enough things to do, and I speak as a J newcomer. There's
> not many languages you can say that about after two and a half years! The
> Zen of J, grasshopper.
>
> Incidentally, is there a way to cap a monadic hook on the left?
> For example (=<.) was mentioned, but obviously it allows dyadic arguments,
> and fails if they are offered.
> Short of wrting monad : 'y=<.y' is there a way I can keep it monadic (and
> implicit)?
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
