
J for C Programmers - mcguire
https://www.jsoftware.com/help/jforc/contents.htm
======
Tomte
Can someone who knows all those one letter languages well succinctly describe
the differences between J, K, Q and APL?

What I think I've got so far (this is all hearsay, and none should be taken as
fact):

APL: The original. Non-ASCII. APLers hate the successors, because "notation is
tool for thought" and ASCII is a poor representation. Main implementations GNU
APL (slowish), Dyalog (fast and expensive, free version available, good
documentation)

K: ASCII, used in finance (among other sibling languages, dependent on the
concrete company and concrete group within a company), comes with kdb+
(columnar data store, integrated with K), very fast (main interpreter loop in
processor cache), one real implementation (very very expensive, limited free
version available), several cvariations on the language, some of them open
source, none comparable

Q: syntax sugar upon K, but otherwise exactly the same

J: another evolutionary strang of APL, impeccable pedigree (Iverson), free
software, experiments more with language features, is more complete when it
comes to the "linguistic" style (adverbs etc.), database available (Jd, but
this database is commercial), slower than K, more extensions like for GUI
programming

~~~
Rampoina
> APLers hate the successors, because "notation is tool for thought" and ASCII
> is a poor representation.

I'm perplexed by this one. I'll concede that the APL symbols are prettier but
why does it magically stop being a notation just because you use combinations
of ASCII symbols. Especially when many APL symbols are composed of units
themselves.

⍲ vs *: One is 'notation' because it has the two units stacked on top of each
other and the other is not because they are stacked horizontally?

~~~
tzs
If a symbol is made of multiple side-by-side ASCII characters, are there any
problems telling where one symbol ends and the next starts?

In ordinary text, we separate words with spaces, and add punctuation at the
end of sentences to further make the structure apparent. (Well, now we do...a
lot of pre-modern writing would justwritethewordssmushedtogetherlikethis [1]).
In most of the sample programs in APL successors I've seen there usually
didn't seem to be space between symbols.

[1] [https://www.bbc.com/culture/article/20150902-the-
mysterious-...](https://www.bbc.com/culture/article/20150902-the-mysterious-
origins-of-punctuation)

~~~
mcguire
Yes, at least for me, trying to learn it. For example, / in many examples is
an "adverb", modifying the previous operator, although xx/ is frequently
introduced as a single thing. (Are all built-in verbs one or two characters?)

~~~
gmfawcett
'xx/' _is_ a single thing -- in the sense that 'xx' is a thing, and '/' is a
thing that modifies other things. By applying '/' to 'xx', you get a new,
standalone thing.

Re: one-or-two characters, there are a few exceptions, like the folds ( F..
F.: etc.) which are new to J9. Also some older ones like {:: (Map) and &.:
(Under) where `x u&.:v y` means `v^:_1 (v x) u v y`. Some of these aren't
verbs but conjunctions, adverbs, etc. For the most part they stick to one or
two. There are parsing rules that dictate what the second and third characters
can be (that's why you see so many colons and periods), and these rules are
actually discussed in the JforC book.

Reading J can be tough, as a fellow learner I feel your pain. :) The one that
usually gets me (in my own code, even!) is

    
    
        5 myverb \ n
    

...which runs the verb over 5-element slices of 'n' at a time, and joins up
the results. The '5' is too far away from the '\', and it can be hard to see
the connection right away. I understand why it's so (it's really running the
modified verb 'myverb\' with arguments 5 and n) but I still find it hard to
read.

When writing my own code, I often leave extra spaces between the multi-
character words, and anywhere else that helps legibility. J might be a terse
language, but there's no point being crazy about it (unless you're golfing).

------
woodrowbarlow
i'm a C programmer, not for any great love of the syntax, but because i cross-
compile for embedded hardware with limited resources and there aren't a lot of
options.

there are also other use cases for C. since it is close to the metal, it is a
good fit for security-sensitive, heavily-audited codebases, because there are
fewer layers of abstraction to audit and a smaller attack surface. manual
memory management makes it a good fit for performance-sensitive applications,
real-time encoding, signal processing, etc., because a garbage collector isn't
competing for CPU time.

there's a lot of overlap between all these use-cases, though, and most of it
comes down to the fact that C:

* is compiled,

* has manual memory management,

* is a relatively small language with a relatively small standard library,

* (and of course, we can't ignore the network effect) is ubiquitous.

so, when i see a document to introduce me to a new language, and it claims to
be written for C developers, the first thing i am going to look for is some
information about the language so that i can judge whether it is even remotely
suitable for the contexts in which i would normally write in C.

i read "foreword", "introduction", "culture shock", and "running a j program",
looking to answer some questions like: is it compiled or interpreted? if
interpreted, how complex is the interpreter? if compiled, does the compiler
use LLVM or some other intermediate AST? is it garbage collected? can the
garbage collector be turned off? how does performance compare?

the only passage that tried to answer "why should i bother?" is a couple of
sentences in the foreword:

> To begin with, for the productivity. J programs are usually a fifth to a
> tenth as long as corresponding C programs, and along with that economy of
> expression comes coding speed. Next, for the programming environment: J is
> an interpreted language, so your programs will never crash, you can modify
> code while it's running, you don't have to deal with makefiles and linking,
> and you can test your code simply by entering it at the keyboard and seeing
> what it does.

all of that is true of python too, but that doesn't mean python can do what i
do with C.

~~~
bgorman
> it is a good fit for security-sensitive, heavily-audited codebases, because
> there are fewer layers of abstraction to audit and a smaller attack surface.

C is a language that has a reason for existing. However C exposes programs to
categories of errors that are not even possible to represent in other
languages. In my opinion security code should be as error proof as possible,
and C is definitely not a good language to accomplish that goal in. (I used to
be a professional C programmer)

~~~
woodrowbarlow
security code should be as _provably_ error-free as possible. C's strength in
this regard is not due to any syntactical strengths, but due to how few layers
exist between the code and the hardware.

it's not the only option, maybe there are even some better options these days
from a purely technical standpoint, but C _is_ used in heavily-audited
security-sensitive applications despite its syntactical/design shortcomings
because it keeps you close to the metal.

~~~
avmich
> C's strength in this regard is not due to any syntactical strengths, but due
> to how few layers exist between the code and the hardware.

Any language compiling into native code has this advantage.

You perhaps meant that in C the programmer actually codes closely to how it's
going to look like in native code. That could be an advantage; but for that C
brings disadvantages, which come from one actually having to code like this -
there is no other way.

The question what's more important - language constructs which are closer to
actual hardware or language abstractions which prevent certain bugs from
appearing - isn't that clear.

------
scottlocklin
One thing to be careful of; J has evolved quite a bit between j805 and
j902[1]. While JforC is usually fairly simple examples, I don't think anyone
has done the work to bring it up to date (in fact it's probably j5 vintage).
Might also be true of the dictionary and some of the phrases. Nuvoc is the
bleeding edge language reference. [2] Great book though; it's how I learned,
more or less, along with the "labs."

[1]
[https://code.jsoftware.com/wiki/System/ReleaseNotes](https://code.jsoftware.com/wiki/System/ReleaseNotes)

[2]
[https://code.jsoftware.com/wiki/NuVoc](https://code.jsoftware.com/wiki/NuVoc)

------
avmich
The whole book is pretty good. After reading and applying the earned knowledge
one wishes the book would be longer, with more material covered, but there are
other books on J, essays and phrases on jsoftware.com, articles and forums -
especially forums.

This book is quite suitable as a first book on the subject. It's a good
reference, too, for basic mechanics; for style in organizing longer thoughts
one would go besides the book.

There easily could be a few "aha" moments while reading. One could be in the
discussion on verb ranks - then the words at the beginning, about the general
commanding the army as a whole, becomes clearer. Another is a classification
of loops - an unusual viewpoint for traditional C approach.

~~~
ggrrhh_ta
I read it putting all of myself into it (even caught a couple of typos/bugs).
I also read Iverson's.

These languages (APL, J, K) promote a programming paradigm that sits somewhere
in between the continuous spectrum between imperative and functional
paradigms.

There is lot of good to absorb from J, and not little of it has fortunately
permeated into the famous Python's numpy library. Many people have been
inadvertently using APL/J deepest concepts thanks to it.

I do think that, even if they are beautiful, they are still generations away
from a community Zeitgeist that would render as widely spread as, for example,
Haskell.

------
mastrsushi
I prefered the sequel K for D programmers.

~~~
giancarlostoro
Funny though anything that competes with D better be damn good. The more I
study and write small projects with D the more I love about D!

~~~
moonchild
It wears off.

I used d for quite a while, and I still think it's much better than c++.
However, it's ultimately just more of the same: an incoherent, tangled mess.
Slightly more coherent, slightly less tangled, sure. It's possible to iterate
on garbage, but you still wouldn't want to serve it at a restaurant. Worse, it
has politics. Prominent d users regularly talk about forking the
language/compiler; not because of any specific language pain points, but
because of pathological problems with the way the language is developed.

The main compiled/native language to watch imo is cone[1], though most of its
ideas are not yet implemented. Zig is also decent, and closer to production-
ready.

1\. [http://cone.jondgoodwin.com/](http://cone.jondgoodwin.com/)

~~~
giancarlostoro
Neat, have you looked at V yet?

[https://vlang.io/](https://vlang.io/)

~~~
moonchild
V is a joke. I don't understand why anyone takes it seriously.

~~~
giancarlostoro
It's current capabilities are probably why. I don't see it as ready yet, but
its interesting how much it does in such a short span of time.

------
michaelcampbell
APL-likes have been a fascination of mine for some years, but sadly at a
distance. For those of you working in these languages, what do you use them
/for/? What industries and/or kinds of applications do you write? Why are
these languages used for them vs others?

I'm looking for some inspiration. (I think) I'd love to use one "for real"/"in
anger" for something but are they too niche to use as CV/Resume enhancement?

~~~
gaze
I took some time and used APL to write a little query DSL for answering
questions about a legacy C++ codebase. I had a collection of little tools that
linked against clang and dumped out XML files containing various cuts of
information of the codebase. I then borrowed some techniques form Aaron Hsu to
do structural queries that joined these tables together in ways that gave me
useful information about the codebase.

It was alright. I don't think I was able to invest enough in APL to make it
really stick but have the impression that if I did it could be very useful.

Fwiw, Aaron Hsu is really the guy to follow for all things APL. He's also
super nice and helpful and a model for anyone who wishes to represent a
technology.

------
moron4hire
In the section on "Culture Shock":
[https://www.jsoftware.com/help/jforc/culture_shock.htm](https://www.jsoftware.com/help/jforc/culture_shock.htm)

    
    
      The triple quotes are ugly.
        Quit bellyaching...
    

I love it. So many arguments in PLT are really just about not ever wanting to
leave ones comfort zone. Sometimes you just have to suck it up and do a thing.

~~~
goto11
I would like to read such a culture shock section for every language I don't
know yet!

I like that it doesn't evangelize and it doesn't disparage C, it just explains
the logic behind the differences.

